Sociale processerSe flere præsentationer fra Mark Masterson. I det sidste indlæg argumenterede jeg for at inkludere E2.
Sig kan lide at tænke på ustruktureret arbejde som et udtryk for forsøg på at håndtere Barely Repeatable Processes (BRP). undtagelser, der hæmmer vores evne til uden problemer at tilføje værdi, selvom vi ellers kunne have en perfekt forretning processer.
Ovenstående diasshow fra Mark Masterson gør opmærksom på, at når vi beskæftiger os med undtagelser, er de bedste værktøjer, vi har til rådighed, den viden, der ligger i folks hoveder. Ergo - argumentet lyder: implementer social software som en måde at indfange den information til nuværende/senere brug. Jeg har ikke et problem med dette bortset fra det som det nu gentages, repræsenterer de fleste af værktøjerne endnu en it-silo uden for procesflowet. Alligevel vil jeg opfordre folk som Mark til at blive ved med at finpudse deres tankegang, så kritikere som mig selv har en chance for at blive overtalt.
jeg vendte tilbage til Sig Rinde der har udviklet en procesmotor de sidste par år designet til at løse dette problem. Han argumenterer for, at kernen af problemet ligger i manglen på granularitet omkring IT-ledede processer, så det er ekstraordinært svært at skære et ødelagt stykke ud, reparere og erstatte. Også selvom udskiftningen er midlertidig, og selvom der er SOA på plads. Jeg tvivler på, at mine venner og fjender hos SAP/Oracle/Microsft/IBM ville protestere mod den udtalelse. Sig siger også, at på grund af det massive spild, han beregner, giver indlejringen af sociale værktøjer i letvægtsprocesmotorgenererede applikationer bare mening.
Det bedste eksempel på en ødelagt proces, jeg kan komme i tanke om, påvirkede mig de sidste par dage, da en bank fordoblede stående ordrer. Den var afhængig af en automatiseret proces, men havde ikke et flag, der sagde noget i stil med: "Hvis du ser dette duplikeret, så bedes du venligst tjek." For at gøre tingene værre var call center-procedurerne så kedelige, at den person, der håndterede opkaldet, ikke havde nogen fornuftig måde at rette op på. det. To timers frustration senere og en supervisor fandt ud af, hvad han skulle gøre. Men først efter at jeg sagde, at blødningen var tydelig. Om min oplevelse er en afviger er en anden sag, men det ville give mening at fange essensen af begivenheden til fremtidig brug, opbygge en proces til at håndtere den og plug-in/out som omstændighederne tilsiger. I den skøre ekstrem kan du argumentere for, at der ikke er behov for at løse problemet, men blot have noget på plads, så processen kan ændres midlertidigt, når det sker. Det tilfredsstiller så alle dem, der er bange for at introducere endnu et potentielt område med processkørhed, indtil det er vist, at vores BRP faktisk er en proces, der let kan gentages.
Sigs nuværende svar på at løse problemet med teknisk-menneskelig grænseflade er at integrere ESME i Thingamy. Se skærmbilledet nedenfor:
Er det så elegant, som det kan være? Måske ikke, men det tager ikke væk fra dets evne til at sidde inde i procesmotorens brugergrænseflade, mens det giver øjeblikkelig værdi tilbage til brugeren. Sigs bud på, hvad han laver, kan findes her.
Det forekommer mig, at selvom du ikke nemt kan eftermontere ERP'er med sociale computing-værktøjer, er der solide argumenter for at have BRP-løsningsteknologi, der inkluderer sociale computing-værktøjer. ESME's integration til Thingamy er måske blot en første iteration, men jeg kan let se, hvordan du kan opdage, få adgang til og vedhæfte f.eks. wiki-indhold og rich media. Det udvider så puljen af viden, som vi kan trække fra, hvilket giver mere potentiel værdi. At tage denne tilgang betyder, at blogs/wiki/Twitteresque-apps pludselig bliver funktioner til integration og ikke fokus for IT-budgetter. Det er et problem for SocialText, Atlassian og Yammers i denne verden, fordi i mit scenarie de forsvinder som diskrete applikationer. Jeg er ikke alene om min tankegang. David Terrar (oplysning: Hans firma Wordframe sponsorerer min personlige weblog) indtager en lignende holdning, selvom han foretrækker et mere eksotisk platformspil, end jeg i øjeblikket forestiller mig.
Beskriver jeg et utopisk syn på verden? Jeg er konstant overrasket over, hvor ofte jeg kan stille et tilsyneladende uskyldigt spørgsmål, kun for at få at vide, at det ikke kan lade sig gøre. Min naturlige tilbøjelighed er at spørge: 'hvorfor?' Hvis vi har brugt billioner af dollars på at skabe stive processer til sikkert håndtere forretningsværdiskabelse, hvorfor skulle det så ikke være moderat nemt at rette, ændre, uanset hvad? Og hvorfor skulle det menneskelige element ikke have en konstruktiv rolle at spille i disse processer? Det er et stort spørgsmål på mange niveauer. Hvis svaret på den første del betyder at optrevle, hvad vi har, så kommer jeg ikke til at lede en meget stor fanklub, hverken inden for IT eller forretning. Hvis jeg kan komme tættere på at finde en bedre måde at komme uden om problemerne, så klarer jeg mig måske bedre. Hvis det giver mig mulighed for effektivt at udskille ineffektivitet, vil jeg have en raveklub på hænderne. Men livet er ikke så enkelt eller for den sags skyld så sort og hvidt.
Michael Bechauf fra SAP og jeg har haft en robust e-mail-samtale omkring dette. Hans synspunkt via e-mail: "... uanset hvor smarte mennesker som Sig er, deres påstand om, at de har fundet den hellige gral at kunne at optimere processer uden den rigide natur, der kræves for effektive processer og softwaresystemer, er bare for godt til at være rigtigt. Det er en flot vision, men ville du virkelig tillade, at landet styres af uforudsigelige processer som Twitter?" Jeg er ikke sikker på, at Sig ville påstå 'hellig gral' status, men hans position er en, der giver meget mening i forbindelse med at løse forretningsproblemer og samtidig omfavne de sociale aspekter, der ledsager dem. Der er en mellemvej her. Folk på sociale medier vil sandsynligvis løfte hænderne i rædsel på Michaels perspektiv. Om du er enig eller ej er irrelevant. Michael siger blot, at blødningen er åbenlys fra udsigtspunktet for en, der bor inde i en organisation, der bygger rigide processer, og som mange tusinde virksomheder, store som små, bygger på stole på. Det er godt forstået, at mange af disse processer er fejlbehæftede. At løse problemerne er uhyre udfordrende. At indlejre de sociale værktøjer i BRP-motorer kan være Michaels og vores flugtvej til at fjerne de 'sociale' konnotationer, som sætter pris på folk som mig, mens de drager fordel af deres effektivitet. Ingen social virksomhedsdesign påkrævet og E2.0 bliver mindre af et lort.
Som afslutning på disse 2 parter vil jeg gerne henvise til et værdifuldt talepunkt fra BabbleWare Inc:
...den nuværende #e20 crowd indser, at de sælger til erhvervslivet, ikke?
Min øjeblikkelige reaktion er - ja - og det er en del af problemet. Så længe jeg kan huske. E2.0-mavens har undgået it-samfundet med den begrundelse, at E2.0 er et forretningsproblem, der er løst med værktøjer, der har den brugervenlighed, der tilbydes af apps i forbrugerkvalitet. Det bringer alle mulige styringsproblemer med sig, som E2.0-spillere kan omgå. Men i de procesledede scenarier, jeg beskriver, er der et bestemt sted for inddragelse af IT. En af grundene til, at ESME-teamet udviklede sig med SAP NetWeaver i tankerne, var, at vi kunne udnytte SAP-sikkerhedsmodellen. Det betød fra et udviklerperspektiv, at det var usandsynligt, at vi ville falde i stykker med ledelsen.
Afsløring: Jeg var en del af det oprindelige ESME-team og udviklede det originale dispositions-marketingmateriale til use case. Jeg har ingen kommerciel aftale med SAP eller nogen med tilknytning til ESME-teamet. Sig er en Enterprise Uregelmæssig hvis radikale synspunkter jeg beundrer, selvom jeg måske ikke altid er enig.
OPDATERING: Et par Twitter-tilhængere har gjort opmærksom på, at den måde, dette præsenteres på, ligner en binær (enten/eller mennesker vs proces) position. Det er en rimelig fortolkning baseret på titlen, men måske mindre, når indholdet er undersøgt. Det, jeg forsøger at understrege, er processens centrale rolle.