Den konventionelle Enterprise 2.0-visdom er, at mennesker betyder noget frem for proces.
Den konventionelle Enterprise 2.0-visdom er, at mennesker betyder noget frem for proces. Det handler om værdi, der kommer fra de sociale relationer mellem mennesker, der styrer vores tilgang til applikationer, der går ind i det næste årti, som en måde at levere den næste bølge af værdi til virksomheden. Mens de forstærkede koncepter omkring E2.0 lægger vægt på ustrukturerede data, emergent adfærd, crowdsourcing og informationssøgning, siger de intet om, hvordan alt dette 'ting' formodes at passe ind i den eksisterende it landskab. Det fremstår som en eftertanke. Det er en farlig måde at tænke på.
Fra 30.000 fod har vi to grundlæggende varianter af E2.0: den, der vender udad som et supplement til eksisterende salgs- og marketingaktiviteter. I dag ser vi, at det udvikler sig til ideen om Social CRM. Den anden kan i store træk indordnes i den generelle idé om forretningssamarbejde. På de samme 30.000 fod har begge fordele som selvstændige koncepter. Begge kan levere i det mindste en vis værdi. Men de går hurtigt i stykker, når vi begynder at undersøge dem i sammenhæng med de eksisterende applikationer landskab og de virksomhedshierarkier, der både understøtter og understøtter det, vi kalder virksomhed DET.
Den anden dag Jeg pegede på det klassiske problem med græstørvskrige og proceshuller som er et fællestræk i forretningsførelsen, og som tjener til at skære på tværs af processer, der involverer mennesker. De kan ikke ignoreres, fordi de altid påvirker virksomheden, ofte med enorme konsekvenser, som det fremgår af historien om nigerianske bukser.
E2.0-mavens har forsøgt at sidespringe dette problem bredt ved at argumentere enten for, at hierarkier vil gå i opløsning nedefra, eller at forretningen kræver et grundlæggende redesign omkring det sociale. Det kan være sandt i videnbaserede virksomheder, men jeg ville være hårdt presset for at se disse ideer slå rod i storskala fremstillings- eller procesindustrier. Begge begreber ignorerer problemet med at styre processen, som er hvor alle forretningshandlinger finder sted, og hvorfra pengeværdien flyder via de transaktioner, som disse processer genererer. Tænk over det. Skaber det faktum, at jeg tweetede noget, eller at jeg annoterede et wiki-indlæg, der anses for at være værdifuldt, pengeværdi på balancen? Selvfølgelig ikke. Det er, hvad der sker, når den ikke-monetære værdi konverteres til rigtige penge, at den bliver genkendelig som havende forretningsværdi. Og til det har vi brug for processer.
I det, vi kunne kalde den 'gamle verden', giver automatiseringsprocesser os mulighed for at blive mere effektive eller, med lidt mere automatisering og tilpasning, mere effektive. Hvorvidt det er opnået, er ikke helt relevant for denne diskussion, selvom det ofte diskuteres. Om vi kan fungere uden IT er en helt anden historie, og det betyder i det mindste en delvis accept af det, vi har. Det er enten det eller spræng hele SAP/Oracle/IBM osv bygningen i luften. Det alternativ er, hvad der ser ud til at være i hovedet på i det mindste nogle E2.0-mavens, selvom jeg ikke kan finde nogen støtte til den holdning fra erhvervslivet.
Brian Sommer har argumenteret for, at nuværende høst af etablerede applikationer er stort set dårligt egnede til den hurtige verden, vi lever i. Han påpeger korrekt de tekniske begrænsninger ved meget virksomhedssoftware. Nøglen til hans argument er, at i det mindste nogle softwarevirksomheder har fundet en vej rundt om problemet. Med andre ord er det måske ikke nødvendigt at smide begreberne ERP osv. ud, men erstatte dem med andre måder at knække procesændringsmøtrikken på.
Alternativt Phil Wainewright argumenterer for noget helt andet:
Jeg tror, vi er ved et gennembrudspunkt, netop fordi teknologien er modnet til det punkt, at den er fleksibel nok til at blive tilpasset, hvad mennesker, der bruger det, forsøger at opnå - for at give dem mulighed for at forfine automatiseringen og processerne, der hjælper dem med at udføre deres roller så effektivt som muligt. Vi behøver ikke længere at bede folk om at ændre deres processer, så de passer ind i kravene til hulkortkørsel eller applikationsovne eller implementerings- og opgraderingscyklusser. Vi har nu informationsteknologi, der er sofistikeret nok til at passe ind i, hvordan mennesker arbejder og opfører sig, og det er derfor, menneskecentreret IT er en definerende tema for det nye årti, der kræver, at informationsteknologer udvikler nye færdigheder og måder at arbejde på, der leverer resultater for folket efterspørgsel.
På trods af Phils mangel på konkrete beviser, er det et ekstremt forførende argument, indtil endnu en gang, du indser, at Phil omgår procesproblemet i sammenhæng med, hvad vi har på vores side bortskaffelse. Sikker på, vi har desperat brug for bedre UX, bestemt forbrugerverdenen har meget at lære, men isoleret set kan de ikke opnå meget, som du ville anerkende som forretningsværdi. Selv med de mest sofistikerede SOA-implementeringer har du stadig problemet med at arbejde i ofte stive procesmiljøer. Hvad skal man gøre?
Hvis vi træder et øjeblik tilbage og ser på de problemer, E2.0 søger at løse, kan du argumentere (i hvert fald fra et samarbejdsperspektiv og muligvis det udadvendte salgs-/markedsføringsvinkel), at de på en meningsfuld måde forsøger at synliggøre information, der tilføjer værdi et sted i proceskæden, og som i sidste ende kan omdannes til penge. Lige nu sker det stort set ikke, undtagen gennem manuel anvendelse og selv da på en kaotisk måde. Noget selvsejrende. Det bringer mig pænt til en e-mail, som SAPs Michael Bechauf har skrevet til ESME Apache inkubatorgruppe. Essensen af det han spørger om er som følger:
Hvad kan mikroblogging-værktøjer som ESME virkelig gøre for at gøre ERP-systemer "bedre"? For mig var dette ikke et teknisk integrationsspørgsmål, men snarere et grundlæggende spørgsmål...
Den måde jeg ser på ERP-systemer er, at en forretningsproces er opdelt i flere trin, der hver især kan udføres med en specifik transaktion. De fleste af disse transaktioner kan også udføres gennem en fjernbetjeningsgrænseflade (WS*, RFC eller hvad som helst), som tilsyneladende ville blive brugt af ESME. Personer med specifikke roller, der bruger ERP-systemet, vil indtaste disse transaktioner, enten udløst af en udefrakommende hændelse (varemodtagelse, oprette salgsordre, forsendelse) eller bedt om gennem en arbejdsgang i system. På en måde er systemet designet og implementeret, så det er tydeligt, hvornår hvem der skal gøre hvad. Succesniveauet for en ERP-implementering afhænger af graden af automatisering, der kan opnås.
Typisk fungerer ERP-systemer bedst med hvad Sig kalder kærligt "Easily Repeatable Processes". En hændelse sker, en passende transaktion udføres, ERP-systemerne bestemmer specifik opfølgningshandling der enten skal udføres manuelt af en person, eller der udløses en opfølgende forretningsproces automatisk. Selv i tilfælde af kundesupport, hvor Twitter siges at have en vis succes på virksomhedsniveau, vil CRM-systemet sørge for, at en kunde supportspecialist vil give en kunde et tilbagekald, og hvis det ikke er sket inden for et bestemt tidsrum, vil en anden kundeservicemedarbejder blive fundet. I bund og grund handler det om forudsigelighed.
Det er klart, at forudsigelighed kun virker, så længe den virkelige verden arbejder synkront med ERP-systemets indre funktioner. I mange tilfælde er det ikke; det er, når folk tager telefoner eller måske bruger et internt mikro-blogging-værktøj. Nogen vil sige, "Hej, jeg har denne kunde, der præsenterer mig for dette problem, nogen derude, der kan hjælpe?".
Men hvilken slags "integration" kræves for at få dette til at ske? Demoerne, der blev vist på Demo Jam, udgav i det væsentlige en begivenhed med en tekst om ESME, men er det ikke i virkeligheden bare nogen, der skriver et spørgsmål? Ville ESME virkelig udløse en forretningsproces gennem en fjernbetjeningsgrænseflade, som at oprette en PO, eller ville ESME-brugeren, Når et spørgsmål er blevet besvaret tilfredsstillende af deres netværk, skal du hellere vende til deres ERP-skærm og indtaste det, de har lært?
Så i bund og grund, hvad jeg siger, er, at jeg ikke tror, at en ESME-integration med ERP vil være af væsentlig værdi. ESME som et selvstændigt værktøj kan meget vel være det, men hvad er så dens sweet spot sammenlignet med Twitter eller sammenlignet med kommercielle værktøjer til implementering på virksomhedsniveau, der allerede er på markedet?
Lad os nedbryde dette, da det på mange måder går til kernen af problemerne omkring E2.0 som anvendt på det eksisterende it-landskab. Jeg skal på dette tidspunkt sige, at Michaels spørgsmål er et, jeg har set stillet på lignende måde af repræsentanter for andre store ERP-spillere, så lad os ikke gå ud fra et minut, at det, jeg refererer til, repræsenterer en individuel. Dette er et stort problem.
I det ideelle IT ERP-landskab leverer automatiserede processer det optimale resultat. I den virkelige verden er det sjældent tilfældet. Eller rettere, det er det sjældent i specifikke anvendelsesområder. Hvis du tænker over det, hvad skal der gå galt med økonomi? Ikke meget. HR administrator? Ikke så meget. CRM? Jep - alle mulige ting. SCM? Masser. Analyser det for at sige branchespecifik ordre til kontantprocesser (som et eksempel), og der er potentielt flere punkter af fiasko, selvom de aggregerede procestrin burde levere mere værdi end at prøve at krydse mange applikationer.
Det ESME DemoJam use case var beregnet til at beskrive et relativt simpelt scenarie, hvor en person var i gang med en proces, der brød sammen. I det demonstrerede anvendelsestilfælde fungerer det som en menneskebaseret opdagelsesmekanisme til problemløsning, der ellers ville blive skovlet ind i et e-mail-spor. Jeg vil derfor hævde, at ESME med sparet tid viste værdi, som kunne omkostningsføres tilbage til procesproblemet. Jeg vil også tilføje, at fordi ESME var integreret i det, der var en NetWeaver-proces, var besparelserne større end at gå ud til en ikke-integreret tjeneste. Med en integreret procesvisning kan mikrobloggingværktøjer levere værdi. Udvid det til blogs/wikier, og du kan argumentere for E2.0-teknologier, der hjælper i tilfælde af ødelagte processer, som let kan rettes. Ja, det har en social komponent, men det er ikke hovedpointen. Det handler om evnen til at udnytte netværket, mens det er i gang.
Så - da vi har ERP, som kan være i stand til varierende automatiseringsniveauer, men som ofte er ufleksibel og/eller risikerer at gå i stykker, hvad skal vi så gøre? Hvordan kan vi optimere processer, fortsætte med at høste fordele af ERP og alligevel styre forbedringer i en hurtig procesverden og samtidig udnytte E2.0-data? Det er emnet for næste indlæg.