Vad är bpm?
Bpm är en systematisk väg till förbättring av ett företags affärsprocesser. En bpm-tillämpning kan exempelvis övervaka mottagande system och kontrollera om något saknas eller guida en anställd genom en felsökning när en beställning inte kommit fram. Det är första gången en teknik används för att skapa fortlöpande samarbete mellan IT och övrig verksamhet som tillsammans skapar tillämpningar som kan integrera människor, processer och information på ett effektivt sätt.
Bpm ger företaget möjlighet att definiera, utföra och finjustera processer som:
• inkluderar interaktioner mellan människor, exempelvis beställningar
• arbetar med flera tillämpningar samtidigt
• hanterar processregler och förändringar dynamiskt, inte bara som statiska flöden (exempelvis uppgifter med flera alternativ och olika resultat).
De viktigaste delarna i bpm är processmodellering (en grafisk beskrivning av en process som blir till en del av tillämpningen och styr hur processen utförs när tillämpningen körs), samt webb- och systemintegrationstekniker där det ingår datasökning via webbläsare. Med hjälp av processmodelleringen går det att styra vem som gör vad och vilka affärssystem som ska användas i processerna. En annan viktig del är vad som brukar kallas processövervakning, en rapporteringsfunktion som anger exakt hur (och hur bra) affärsprocesserna och arbetsflödet fungerar.
Att optimera processer som involverar människor och pågående förändringar brukar vara svårt. Ett hinder för optimering har ofta varit att både processerna och ansvaret för dem inte varit självklart, speciellt när det gäller processer som används av flera delar eller affärsenheter i verksamheten. Dessutom ändras verksamheten ofta snabbare än IT-avdelningen hinner uppdatera de tillämpningar som verksamheten behöver, vilket hämmar innovationer, tillväxt och prestanda och så vidare. Men idag gör den utbredda användningen av webbläsare och framväxten av enkla integrationstekniker för tillämpningar som soap/xml att IT-avdelningen kan införa tekniker som stöder affärsverksamheten, oavsett vilken organisatorisk funktion eller teknik det gäller.
Hur fungerar bpm i praktiken?
En stor återförsäljare köper en personaltillämpning för att effektivisera personalhanteringen. Personalavdelningen, som är placerad på företagets huvudkontor, får den nya tillämpningen och kan förmodligen förbättra personalhanteringsprocesserna med hjälp av funktionerna i den nya programvaran. Men ofta förekommande aktiviteter som anställningar, avsked, löneförändringar med mera händer ute i företagets butiker, snarare än på huvudkontoret. Butikscheferna använder inte tillämpningen själva, utan skickar information till personalavdelningen på huvudkontoret där de ansvariga lägger in informationen i systemet.
Men bpm kan butikschefer, med hjälp av webb- och integrationstekniker, få tillgång till processer och användargränssnitt för alla personaltransaktioner de behöver, samtidigt som de för in den information personalavdelningen behöver i systemet och automatiskt överför den till huvudkontoret och de tillämpningar personalavdelningen använder.
Ett annat exempel: Personalen på supportavdelningen hos en återförsäljare använder en webbaserad tillämpning för att hantera returer av varor som köpts på olika sätt och vid olika tillfällen (vilket innebär att de omfattas av olika delar av företagets returpolicy). Vad en bpm-tillämpning skulle kunna göra här är att guida användarna genom de olika stegen för retur av varor. Om olika regler finns inbyggda i systemet behöver personalen inte kontakta sin chef vid frågor eller för godkännande av returer (såvida inte tillämpningen anger att det ska ske).
För att kunna avsluta transaktionen måste bpm-tillämpningen använda sig av de företagsomspännande affärssystem där den nödvändiga informationen finns, exempelvis kundregister, lagersystem eller logistiksystem. Men personalen på supporten ser bara en tillämpning och slipper jaga rätt på informationen i flera olika system. Den tillämpning som används körs på en bpm-plattform med olika verktyg för att:
• affärsanalytiker ska kunna skapa modeller av och ändringar i returprocesserna och definiera de företagsregler som ska styra processerna
• IT-avdelningen ska kunna integrera de affärssystem som behövs i tillämpningen
• samarbetsgrupper ska kunna bygga tillämpningar för slutanvändare där processer och regler används
• ledningen ska kunna granska processhanteringen (till exempel för prognoser av förväntade kundintäkter) eller till och med ändra parametrar i realtid (exempelvis att öka den förväntade intäktsnivån under toppar för att få cheferna att granska sin verksamhet och godkänna kundintäkter).
Med den ledande bpm-plattformen arbetar alla i en gemensam modell, vilket innebär att ändringar i processen kan realiseras mycket snabbt. Den typen av plattformar kan kallas bpm-programsviter eftersom de erbjuder integrerad processmodellering, realtidsövervakning och rapporter från chefer – allt för att underlätta förändringar av processer.
Vad har bpm som andra företagstillämpningar saknar?
Bpm-programsviter är integrerade verktyg för att bygga upp och underhålla skräddarsydda lösningar, baserade på företagets egna, unika affärsprocesser. Andra företagstillämpningar består oftast av fasta funktioner, exempelvis personaltillämpningar som brukar ha vissa möjligheter till anpassning med hjälp av inställningar. Det innebär oftast att företag som skaffar en sådan tillämpning måste välja mellan att använda tillverkarens inbyggda affärsprocesser eller också få tillverkaren att göra kostsamma förändringar som också gör att uppgraderingar blir mycket dyra eller omöjliga. Bpm fungerar inte så, utan möjliggör för en kostnadseffektiv och snabb modellering och ändring av affärsprocesserna så att företagets specifika behov kan uppfyllas.
Vissa företagstillämpningar har inbyggda arbetsflödesfunktioner så användarna får viss möjlighet att styra hanteringen av dokument som fakturor och tekniska specifikationer. Men bpm går ett steg längre än traditionella arbetsflödestillämpningar. För det första så implementeras de flesta arbetsflödestillämpningar via kod, som måste utvecklas och underhållas av programmerare. Bpm använder grafiska processmodelleringsverktyg som låter företagets användare och analytiker – de som kan processerna bäst – att implementera och underhålla processdefinitionerna. För det andra handlar arbetsflöden i traditionell mening oftast om fördelning av dokument eller uppgifter. I bpm har arbetsflödet utökats med hjälp av inbyggd funktionalitet för utökade användargränssnitt, systemintegration, regelhantering (de regler som krävs för att kunna använda processer med flera alternativa resultat), exempelvis att en beställning under 500 dollar inte kräver chefens godkännande, men att det krävs vid beställningar på mer än det beloppet, eller vid vissa händelser (till exempel om en produkt ska dras tillbaka så måste butikskedjorna meddelas om att den ska tas bort från hyllorna).
BPM används ofta för att integrera flera företagstillämpningar samt olika interna och externa användare i nya processer. Om företagstillämpningarna integreras blir det enklare att flytta data mellan dem. Bpm involverar även användarna och skapar möjlighet till varaktiga processer. Människorna involverar användarna på två sätt:
För de vanliga användarna skapar bpm arbetsuppgifter med utgångspunkt i affärsprocesserna, där varje uppgift innehåller instruktioner för hur den ska utföras, status, prioritet, när det ska vara klart och andra attribut. De vanliga användarna använder bpm för att övervaka och utföra sina egna eller de arbetsuppgifter som tilldelats den arbetsgrupp de tillhör.
Chefer och arbetsledare kan använda bpm för att övervaka hur processerna fungerar. De kan få statusrapporter med grafik för enskilda uppgifter som alarmerar vid flaskhalsar i processerna. De kan också regelbundet involveras i arbetsuppgifterna genom processer som kräver att chefen godkänner vissa steg.
Många bpm-produkter ger insikt i processarbetet i realtid. Bpm-modellen för processflöde ger ledningen möjlighet att enkelt identifiera flaskhalsar och ineffektiva delar av processerna, men även att mycket enklare förändra processerna för att förbättra produktiviteten.
Hur går bpm ihop med affärssystem, erp och andra företagstillämpningar?
En fördel med många bpm-produkter är att de är enkla att integrera med andra tillämpningar. Många företagstillämpningar fungerar separat från alla andra system på företaget, och fokuserar på att lösa specifika problem, vilket gör interaktion eller datadelning med andra tillämpningar svårt eller till och med omöjligt. Det innebär att bpm ofta är ett idealiskt sätt att automatisera processer som kräver information från flera olika företagstillämpningar. Att underlätta informationsflödet mellan de olika affärssystemen kan ofta innebära betydande produktivitetsökningar.
När det stod klart att erp skulle bli en betydande del av företagssystemen, började leverantörer av mellanvara att ta fram lösningar för de växande integrationsproblemen mellan olika system. Vas som återstod var kanske den svåraste automatiseringen av alla – processer som ändrar eller engagerar flera subsystem, externa processer, eller system som står utanför företagets kontroll och den kanske största utmaningen – flera människor.
Bpm kan ses som ett integrationslager som automatiserar processer där affärssystem och andra företagssystem ingår, men också vägleder användarna genom nya processer. En vanlig företagsprocess (exempelvis introduktion av en ny produkt) involverar flera olika ansvarsområden på företaget, och bpm kan integrera de olika områdena och de befintliga systemen inom varje område.
För företag som redan har soa-anpassat sina affärssystem innebär bpm en snabb lösning på processproblemen. Hos de företag som varken har soa eller någon plattform för mellanvara kommer bpm att kräva anpassad integration till de system och den information som används. Behovet av anpassad integration utgör oftast inte något hinder för bpm, eftersom många moderna system har api-gränssnitt, eller om det inte finns, stöd för integration direkt till databas via sql.
Bpm-programsviter kan också användas för att lägga samman flera tillämpningar, det vill säga att anpassa en lösning som köpts in av en avdelning så att den även kan användas av andra avdelningar. Bpm fungerar som ett paraplysystem, definierar processer och använder sina funktioner för systemintegration utan att användarna märker några förändringar eller försämringar av prestanda. En sammansatt tillämpning hämtar sin funktionalitet från ett antal befintliga källor inom soa för att skapa nya tjänster. Med bpm är det enkelt att bygga upp sammansatta tillämpningar som annars skulle bli för kostsamma eller riskabla att skaffa eftersom man då skulle tvingas att ändra i de befintliga tillämpningarna.
Vilka typer av företagsprocesser är de bästa att använda med bpm?
Bpm-investeringar brukar ge goda resultat (roi) inom följande områden:
De områden där bpm inte passar är följande:
Ibland är den viktigaste delen av en strategi att veta vad man inte bör göra, speciellt när det gäller relativt horisontella system som bpm. Ett första försök med bpm bör ske med en process som är viktig, men inte den mest verksamhetskritiska på företaget. När bpm utförs på rätt sätt sätts stenen i rullning, om man fokuserar på en specifik och snabb lösning för en synlig förbättring av en process kommer det att kunna medföra större bpm-implementering på bred front.
Det verkar som om alla säljer bpm, men hur ser bpm-marknaden ut?
Leverantörerna har ett brett spektrum av lösningar som är utformade för många olika branscher och behov. På den mest avancerade nivån finns det i stort sett två olika typer av leverantörer, de som erbjuder bpm som en del av affärssystem och de som säljer separata bpm-programsviter. Ibland går det att köpa bpm-lösningar i den första kategorin, separat från affärssystemet, och ibland går det inte. Till exempel innehåller Filenets P8 processkapacitet som bara kan användas som man använder Filenets ECM-lösning, medan SAPs Netweaver-teknik kan användas fristående.
Leverantörer som erbjuder bpm som en del av ett affärssystem brukar erbjuda bpm-funktionalitet som fokuserar på, och utökar affärssystemsarktitekturen. Till exempel kan en leverantör av dokumenthanteringssystem erbjuda dokumentcentrerade bpm-funktioner, medan en leverantör av mellanvara betonar dataintegrationen i sin bpm-lösning. Bpm-funktioner i affärssystem består oftast av tilläggsteknik som köpts in från andra leverantörer och kopplats samman med systemet i fråga, vilket inte borgar för en särskilt stabil lösning. Men givetvis har båda typerna av lösningar sina nackdelar och fördelar.
Nytt på bpm-marknaden är lösningar med öppen källkod. De mest välkända är JBPM från JBoss. De senaste versionerna av JBPM har blivit avsevärt bättre än tidigare, men det saknar många av de funktioner som ingår i plattformar från de ledande kommersiella bpm-systemleverantörerna som Lombardi Software, Pegasystems och Savvion (som inte erbjuder lösningar med öppen källkod). De bpm-funktioner som ingår i JBPM är inte lika stabila som de i de många kommersiella produkter där modellsimulering och utveckling av grafiska användargränssnitt ingår.
Det finns vissa nyckelbegrepp som den som ska välja bpm-leverantör inte bör glömma:
Vad är skillnaden mellan bpm och serviceorienterad arkitektur, soa?
Soa ger tillgång till andra tillämpningar. Bpm använder soa för att inkludera information från dessa tillämpningar i en förbättrad process. Om soa utgör en väg till informationen, så är bpm den funktion som följer vägen genom infrastrukturen för att uträtta användbara saker.
I ett nötskal ger soa möjlighet att skapa tjänster som stödjer affärsprocesser som kan kombineras för en mer flexibel verksamhet. I mer tekniska termer är soa ett ramverk för integration och arkitektur som stödjer löst sammankopplade tjänster och möjliggör integration av nya och gamla affärssystem. Det låter dessa system visa sin funktionalitet för andra tillämpningar på ett standardmässigt sätt. Till exempel kan ett betalnings- och kontosystem tilldelas ett gränssnitt som låter andra tillämpningar att lägga in betalningar i systemet. Med bpm går det att kombinera olika tjänster från olika tillämpningar i nya processer.
Ibland kan en bpm-satsning utgöra startpunkt för en soa-strategi. Vi lever i en värld där företagsledningar vill se resultat av sina IT-investeringar på en gång och då kan soa vara svårt att sälja in eftersom det är svårt att förklara värdet av soa i konkreta och lättförståeliga termer. En strategi för att komma runt detta hinder är att förklara hur soa kan underlätta bpm, eftersom bpm är mer konkret. Det är lätt att förklara vad det är värt att underlätta och effektivisera specifika och verksamhetskritiska processer, och i det sammanhanget kan soa ingå som en del.
Men en av de saker man bör vara medveten om handlar om kvaliteten på de tjänster som kan levereras av de tillämpningar som utgör soa-tjänsten. Det är speciellt viktigt när leverantörerna av dessa tjänster finns på andra delar av företaget eller kanske till och med på andra företag. Tillämpningar som använder sådana gränssnitt måste utformas så att de kan fungera när de externa tjänsterna inte finns tillgängliga. Företaget måste skaffa ett avtal med sina soa-partners som reglerar kvaliteten på de levererade tjänsterna. I sådana avtal bör det ingå överenskommelser om när och hur gränssnitten ska uppgraderas. Saken är den att om man använder soa som en integrationsstrategi för bpm så kommer man att ha verksamhetskritiska affärsprocesser som förlitar sig på dessa tjänster. Om tjänsterna inte finns tillgängliga så kommer de bpm-styrda affärsprocesserna inte att fungera. Därför bör man vara säker på att man kan garantera och kontrollera kvaliteten på alla tjänster bpm-lösningen baseras på.
Finns det några standarder för bpm?
Ja, förespråkare för bpm försöker följa samma väg som andra tekniker lyckats med och vill etablera en solid grund av industristandarder som stödjer fortsatt tillväxt och accepteras av kunderna.
Kunderna är intresserade av standarder eftersom det underlättar för dem att flytta sina tillämpningar till andra bpm-leverantörer, hitta utvecklare och integrera med andra bpm-system och externa partners, och även att minska kostnaderna. Olyckligtvis har den breda funktionaliteten som ingår i ett ordinärt bpm-system och det otal antal intressegrupper som finns enbart resulterat i framväxande standarder för delar av den vanliga ledningsprocessen (design, utförande, underhåll).
De viktigaste standarderna idag:
Det viktigaste att tänka på i det här sammanhanget är att alla dessa standarder (och alla de övriga som inte finns med på listan) bara fokuserar på en liten del av en bpm-produkt. Den stora utmaningen blir att integrera alla dessa standarder i ett kontinuerligt förlopp för processförbättring med bpm.
Finns det då några standarder under utveckling som tillåter överföring av kompletta bpm-tillämpningar mellan olika leverantörer? Nej. Standarder kan i framtiden komma att medföra utveckling av närliggande produkter (exempelvis verktyg för rapportering och analys) som hanterar en del bpm-data, men idag spelar de befintliga standarderna inte någon större roll för bpm-produkter (annat än i marknadsföringssammanhang).
De mest betydelsefulla standarderna idag är finns i områden som är viktiga för bpm, som soa, xml, dokumentationsstandarder och så vidare.
Vad kostar bpm? Vilka är de dolda kostnaderna?
Ett normalt bpm-projekt innebär licensiering av ett bpm-system från en leverantör, utbildning av personalen och att anlita extern hjälp för att komma igång med bpm-satsningen. Precis som för andra programplattformar finns det ett antal olika typer av licenser att tillgå, exempelvis företagsavtal, per processor, per process, per utvecklare, per användare etcetera.
Idag börjar bpm få fotfäste på många stora företag, vilket gör att bpm-leverantörerna siktar in sig på medelstora företag och minskar licensavgifterna för att de mindre företagens budgetar ska klara kostnaden.
En normal implementering med ett av de ledande bpm-systemen kostar mellan 250 000 och 500 000 dollar för att kunna hantera någon av företagets viktigaste processer. Kostnaden inkluderar de två första punkterna nedan.
Potentiella dolda kostnader kan inkludera:
• Licenser till och införande av flera olika utvecklings-, test- och produktionsmiljöer som stödjer flera samtidiga bpm-satsningar.
• Extra program- och serverdatabaslicenser.
• Personal som hanterar och matar in data i servrarna
• Interna kostnader för att få med användarna i processmodelleringen, framtagningen av definitioner för processregler, utveckling av användargränssnitt, test och genomförande.
• Lednings- och utbildningskostnader för att övertyga användarna om det positiva i en övergång från händelsestyrda till uppgiftsstyrda arbetsuppgifter. Händelsestyrda arbetsuppgifter betyder att användarna "vet" vilka uppgifter de ska utföra och i vilken ordning de ska utföras eftersom de alltid gjort så, de prioriterar arbetsuppgifterna beroende på vad som inträffar och när det händer, ofta enligt modellen att det som inte är trasigt behöver inte åtgärdas. Uppgiftsstyrt arbete innebär att den logik som byggts in i bpm-lösningen definierar arbetsuppgifterna samt vilken ordning de ska utföras i och vilken prioritet de ska ha. Användarna övervakar en att göra-lista för att få reda på vad de ska arbeta med.
Vad ingår i implementering av bpm?
På samma sätt som implementering av andra program kräver bpm både verksamhetsmässiga och tekniska resurser och aktiviteter. Effektiv bpm baseras på en kontinuerlig process av design, utveckling och leverans. Även om de vanliga personerna ingår i projektet (exempelvis sponsorer från ledningen, projektledare, användare, analytiker, systemarkitekter, kvalitets- och infrastrukturspecialister) så kan deras roller i bpm-projektet te sig något annorlunda.
Vid en normal implementering av ett bpm-paket hos ett företag finns användarna med på kravspecifikations- och planeringsstadiet. Efter det är de vanligtvis inte involverade alls, förrän det blir dags för användartester. En bpm-implementation kommer de dock att kräva kontinuerligt deltagande från nyckelanvändare på verksamhetssidan och affärsanalytiker när processmodellerna utvecklas och de tillämpningselement som ska stötta dem implementeras i olika steg. Användare på verksamhetssidan och IT-personalen är oftast inte vana vid ett kontinuerligt samarbete för att implementera program, vilket också innebär att planering, utbildning och ledning blir nyckelbegrepp för en lyckad bpm-implementering.
En annan tänkbar utmaning med bpm är det ändrade beteende som krävs av dem som deltar i processen. Ofta kräver bpm att användarna förändrar sättet de utför sina arbeten på, från händelsestyrda arbetsuppgifter till uppgiftsstyrda, de senare styrs av de regler och prioriteringar som finns inbyggda i bpm-systemet.
För många av de anställda kommer bpm att innebära att de kommer att övervaka en inkorg där arbetsuppgifterna levereras med förinställd prioritering och instruktioner för hur de ska utföras, i stället för att utföra de uppgifter som verkar mest angelägna. På vissa företag kommer det att räcka med väl planerad och genomförd utbildning för att klara övergången, men hos andra kan implementering av uppgiftsstyrda arbetsprocesser kräva en större förändring av hela företagskulturen.
10 tankeställare från genomförda bpm-projekt
Gör
Börja med en viktig process som är viktig för företaget.
Undvik
Att försöka fixa till den mest avancerade processen eller att göra allt samtidigt.
Gör
Ta fram ett enkelt räntabilitetsmått för projektet som är meningsfullt för företaget.
Undvik
Att göra för många eller för avancerade mätningar av processutförandet.
Gör
Sluta modellera, börja implementera.
Undvik
Att vänta tills alla är överens om den nya processen innan installation och testgenomförande.
Gör
Insistera på ett iterativt genomförande i flera steg, med olika delmål.
Undvik
Att projektlängden blir alltför flexibel – den första processen bör fungera inom 60 till 90 dagar då det bör finnas en fastställd plan för framtida installationer.
Gör
Använd de egna affärsprocessernas behov vid jämförelse av offerter.
Undvik
Att fokusera för mycket på tekniken eller att tro att alla bpm-system är likadana.
Hur brukar företag organisera sina bpm-projekt? Vem ska ansvara för bpm-satsningen, verksamheten eller IT?
I ett normalt bpm-projekt ingår en sponsor från ledningen, analytiker från verksamhetssidan som har detaljkunskap om processerna, IT-personal som kan ta fram relevanta data och integrera system, samt utvecklare som kan bygga gränssnitt som vägleder användarna genom den nya processen. Konsulter finns ofta med i det första projektet, men målet är att företaget ska kunna klara av framtida bpm-satsningar på egen hand. Bpm-satsningar kräver ofta att personal från olika funktioner inom företaget deltar. Projektgruppen kan likna ett vanligt IT-projekt, med den skillnaden att personal från verksamhetssidan deltar i processmodellering och utformning av gränssnitt.
Bpm kommer oftast in i företaget från IT-avdelningen. Det innebär ibland att IT får huvudansvaret för projektet, speciellt om det är första gången. IT-avdelningens inblandning i alla företagets funktioner passar också bra ihop med den företagsomspännande bpm-kapaciteten. Många företag har skapat interna grupper som arbetar med förbättringar av processer och bpm blir då en naturlig del av ett sådant arbete.
Men bpm är ett sätt att kontinuerligt effektivisera processerna som går utanför det rent tekniska. Kontinuerlig processförändring kräver en ingående kunskap om processerna och vad förbättringar av dem kommer att innebära. Dessutom måste bpm-gruppen ha möjlighet att fatta beslut snabbt. Dessa faktorer gör det mer lämpligt att verksamhetssidan/ledningen leder och driver bpm-projektet och att IT-sidan underlättar, skapar exempel och sköter integrationen mellan system.
Hur får man ledningen att godkänna ett bpm-projekt?
För det första måste man analysera om bpm skulle kunna fungera inom det egna företaget eller om det bara skulle innebära merarbete. Det gäller att komma ihåg att bpm är ett sätt att lösa problem av det slaget och förmodligen kommer att överleva specifika leverantörsplattformar på företaget.
Bpm ger bäst resultat om det används på hela företaget, men det införs oftast för att lösa ett specifikt problem med en process. Sedan sprider det sig naturligt när folk ser internt vilka resultat som kan uppnås och börjar införa bpm i andra problematiska processer. Till exempel brukar den första processen där bpm införs på företag vara personalsystemet.
Fem steg till att få ledningens godkännande av ett bpm-projekt
1. Identifiera tänkbara problemområden eller processer som inte fungerar
2. Välj ut ett par av dem och analysera vilka specifika vinster som kan uppnås med vart och ett. Ställ upp det i tabellform.
3. Skapa en modell för räntabilitet (roi).
4. Lägg fram tänkbara omsättningsökningar, kostnadsbesparingar och fördelar som uppnås genom att vissa kostnader undviks.
Hur mäter och uppnår man räntabilitet (roi) i ett bpm-projekt?
Att lyckas med bpm handlar oftast om att ha enkla affärsmässiga mätpunkter, som exempelvis:
• Mindre antal återlämnade leveranser.
• Mindre tid går åt för hantering av specialbeställningar.
• Mer återbetalningar till företaget vid kredittvister.
• Mer metodiskt slutförande av uppgifter/ökad produktivitet.
• Mindre tid går åt för utbildning av nyanställda.
Om det inte går att identifiera en måttstock som är meningsfullt för dem som ansvarar för verksamheten så bör man förmodligen ta ett steg tillbaka och utvärdera om man verkligen identifierat rätt målprocess för bpm.
Att ha rätt måttstock hjälper också projektgruppen att hålla det som är viktigt i fokus och ledningen engagerad. Eftersom bpm är en iterativ lösning är det extremt viktigt att alla inblandare försöker lösa begränsningarna början och verkligen får lösningen att användas i verksamheten. Mätningar och rapporter om resultat är ett krav, speciellt eftersom det innebär förändringar av det dagliga arbetet för användarna.
Till exempel om förväntningarna på en process läggs upp som arbetsuppgifter på en användarportal, behöver ledningen bara övervaka användningen av och genomströmning på den portalen. Om användarna inte utnyttjar portalen tillräckligt ofta kan bpm-lösningen modifieras så att arbetsuppgifterna skickas via e-post till användarens inkorg i stället för till portalen.
Sammanfattningsvis, för att man ska kunna få ut maximal vinst av bpm krävs det att man:
• väljer rätt målprocesser
• sätter samman rätt arbetsgrupp
• använder en iterativ projektmetodik
• behåller fokus på de affärsmässiga målen för att åstadkomma fler förbättringar och öka användarnas engagemang.
Text: Mark Cooper och Paul Patterson, grundare respektive delägare av Athens Group
Översättning: Lotta Kempe
Bpm är en systematisk väg till förbättring av ett företags affärsprocesser. En bpm-tillämpning kan exempelvis övervaka mottagande system och kontrollera om något saknas eller guida en anställd genom en felsökning när en beställning inte kommit fram. Det är första gången en teknik används för att skapa fortlöpande samarbete mellan IT och övrig verksamhet som tillsammans skapar tillämpningar som kan integrera människor, processer och information på ett effektivt sätt.
Bpm ger företaget möjlighet att definiera, utföra och finjustera processer som:
• inkluderar interaktioner mellan människor, exempelvis beställningar
• arbetar med flera tillämpningar samtidigt
• hanterar processregler och förändringar dynamiskt, inte bara som statiska flöden (exempelvis uppgifter med flera alternativ och olika resultat).
De viktigaste delarna i bpm är processmodellering (en grafisk beskrivning av en process som blir till en del av tillämpningen och styr hur processen utförs när tillämpningen körs), samt webb- och systemintegrationstekniker där det ingår datasökning via webbläsare. Med hjälp av processmodelleringen går det att styra vem som gör vad och vilka affärssystem som ska användas i processerna. En annan viktig del är vad som brukar kallas processövervakning, en rapporteringsfunktion som anger exakt hur (och hur bra) affärsprocesserna och arbetsflödet fungerar.
Att optimera processer som involverar människor och pågående förändringar brukar vara svårt. Ett hinder för optimering har ofta varit att både processerna och ansvaret för dem inte varit självklart, speciellt när det gäller processer som används av flera delar eller affärsenheter i verksamheten. Dessutom ändras verksamheten ofta snabbare än IT-avdelningen hinner uppdatera de tillämpningar som verksamheten behöver, vilket hämmar innovationer, tillväxt och prestanda och så vidare. Men idag gör den utbredda användningen av webbläsare och framväxten av enkla integrationstekniker för tillämpningar som soap/xml att IT-avdelningen kan införa tekniker som stöder affärsverksamheten, oavsett vilken organisatorisk funktion eller teknik det gäller.
Hur fungerar bpm i praktiken?
En stor återförsäljare köper en personaltillämpning för att effektivisera personalhanteringen. Personalavdelningen, som är placerad på företagets huvudkontor, får den nya tillämpningen och kan förmodligen förbättra personalhanteringsprocesserna med hjälp av funktionerna i den nya programvaran. Men ofta förekommande aktiviteter som anställningar, avsked, löneförändringar med mera händer ute i företagets butiker, snarare än på huvudkontoret. Butikscheferna använder inte tillämpningen själva, utan skickar information till personalavdelningen på huvudkontoret där de ansvariga lägger in informationen i systemet.
Men bpm kan butikschefer, med hjälp av webb- och integrationstekniker, få tillgång till processer och användargränssnitt för alla personaltransaktioner de behöver, samtidigt som de för in den information personalavdelningen behöver i systemet och automatiskt överför den till huvudkontoret och de tillämpningar personalavdelningen använder.
Ett annat exempel: Personalen på supportavdelningen hos en återförsäljare använder en webbaserad tillämpning för att hantera returer av varor som köpts på olika sätt och vid olika tillfällen (vilket innebär att de omfattas av olika delar av företagets returpolicy). Vad en bpm-tillämpning skulle kunna göra här är att guida användarna genom de olika stegen för retur av varor. Om olika regler finns inbyggda i systemet behöver personalen inte kontakta sin chef vid frågor eller för godkännande av returer (såvida inte tillämpningen anger att det ska ske).
För att kunna avsluta transaktionen måste bpm-tillämpningen använda sig av de företagsomspännande affärssystem där den nödvändiga informationen finns, exempelvis kundregister, lagersystem eller logistiksystem. Men personalen på supporten ser bara en tillämpning och slipper jaga rätt på informationen i flera olika system. Den tillämpning som används körs på en bpm-plattform med olika verktyg för att:
• affärsanalytiker ska kunna skapa modeller av och ändringar i returprocesserna och definiera de företagsregler som ska styra processerna
• IT-avdelningen ska kunna integrera de affärssystem som behövs i tillämpningen
• samarbetsgrupper ska kunna bygga tillämpningar för slutanvändare där processer och regler används
• ledningen ska kunna granska processhanteringen (till exempel för prognoser av förväntade kundintäkter) eller till och med ändra parametrar i realtid (exempelvis att öka den förväntade intäktsnivån under toppar för att få cheferna att granska sin verksamhet och godkänna kundintäkter).
Med den ledande bpm-plattformen arbetar alla i en gemensam modell, vilket innebär att ändringar i processen kan realiseras mycket snabbt. Den typen av plattformar kan kallas bpm-programsviter eftersom de erbjuder integrerad processmodellering, realtidsövervakning och rapporter från chefer – allt för att underlätta förändringar av processer.
Vad har bpm som andra företagstillämpningar saknar?
Bpm-programsviter är integrerade verktyg för att bygga upp och underhålla skräddarsydda lösningar, baserade på företagets egna, unika affärsprocesser. Andra företagstillämpningar består oftast av fasta funktioner, exempelvis personaltillämpningar som brukar ha vissa möjligheter till anpassning med hjälp av inställningar. Det innebär oftast att företag som skaffar en sådan tillämpning måste välja mellan att använda tillverkarens inbyggda affärsprocesser eller också få tillverkaren att göra kostsamma förändringar som också gör att uppgraderingar blir mycket dyra eller omöjliga. Bpm fungerar inte så, utan möjliggör för en kostnadseffektiv och snabb modellering och ändring av affärsprocesserna så att företagets specifika behov kan uppfyllas.
Vissa företagstillämpningar har inbyggda arbetsflödesfunktioner så användarna får viss möjlighet att styra hanteringen av dokument som fakturor och tekniska specifikationer. Men bpm går ett steg längre än traditionella arbetsflödestillämpningar. För det första så implementeras de flesta arbetsflödestillämpningar via kod, som måste utvecklas och underhållas av programmerare. Bpm använder grafiska processmodelleringsverktyg som låter företagets användare och analytiker – de som kan processerna bäst – att implementera och underhålla processdefinitionerna. För det andra handlar arbetsflöden i traditionell mening oftast om fördelning av dokument eller uppgifter. I bpm har arbetsflödet utökats med hjälp av inbyggd funktionalitet för utökade användargränssnitt, systemintegration, regelhantering (de regler som krävs för att kunna använda processer med flera alternativa resultat), exempelvis att en beställning under 500 dollar inte kräver chefens godkännande, men att det krävs vid beställningar på mer än det beloppet, eller vid vissa händelser (till exempel om en produkt ska dras tillbaka så måste butikskedjorna meddelas om att den ska tas bort från hyllorna).
BPM används ofta för att integrera flera företagstillämpningar samt olika interna och externa användare i nya processer. Om företagstillämpningarna integreras blir det enklare att flytta data mellan dem. Bpm involverar även användarna och skapar möjlighet till varaktiga processer. Människorna involverar användarna på två sätt:
För de vanliga användarna skapar bpm arbetsuppgifter med utgångspunkt i affärsprocesserna, där varje uppgift innehåller instruktioner för hur den ska utföras, status, prioritet, när det ska vara klart och andra attribut. De vanliga användarna använder bpm för att övervaka och utföra sina egna eller de arbetsuppgifter som tilldelats den arbetsgrupp de tillhör.
Chefer och arbetsledare kan använda bpm för att övervaka hur processerna fungerar. De kan få statusrapporter med grafik för enskilda uppgifter som alarmerar vid flaskhalsar i processerna. De kan också regelbundet involveras i arbetsuppgifterna genom processer som kräver att chefen godkänner vissa steg.
Många bpm-produkter ger insikt i processarbetet i realtid. Bpm-modellen för processflöde ger ledningen möjlighet att enkelt identifiera flaskhalsar och ineffektiva delar av processerna, men även att mycket enklare förändra processerna för att förbättra produktiviteten.
Hur går bpm ihop med affärssystem, erp och andra företagstillämpningar?
En fördel med många bpm-produkter är att de är enkla att integrera med andra tillämpningar. Många företagstillämpningar fungerar separat från alla andra system på företaget, och fokuserar på att lösa specifika problem, vilket gör interaktion eller datadelning med andra tillämpningar svårt eller till och med omöjligt. Det innebär att bpm ofta är ett idealiskt sätt att automatisera processer som kräver information från flera olika företagstillämpningar. Att underlätta informationsflödet mellan de olika affärssystemen kan ofta innebära betydande produktivitetsökningar.
När det stod klart att erp skulle bli en betydande del av företagssystemen, började leverantörer av mellanvara att ta fram lösningar för de växande integrationsproblemen mellan olika system. Vas som återstod var kanske den svåraste automatiseringen av alla – processer som ändrar eller engagerar flera subsystem, externa processer, eller system som står utanför företagets kontroll och den kanske största utmaningen – flera människor.
Bpm kan ses som ett integrationslager som automatiserar processer där affärssystem och andra företagssystem ingår, men också vägleder användarna genom nya processer. En vanlig företagsprocess (exempelvis introduktion av en ny produkt) involverar flera olika ansvarsområden på företaget, och bpm kan integrera de olika områdena och de befintliga systemen inom varje område.
För företag som redan har soa-anpassat sina affärssystem innebär bpm en snabb lösning på processproblemen. Hos de företag som varken har soa eller någon plattform för mellanvara kommer bpm att kräva anpassad integration till de system och den information som används. Behovet av anpassad integration utgör oftast inte något hinder för bpm, eftersom många moderna system har api-gränssnitt, eller om det inte finns, stöd för integration direkt till databas via sql.
Bpm-programsviter kan också användas för att lägga samman flera tillämpningar, det vill säga att anpassa en lösning som köpts in av en avdelning så att den även kan användas av andra avdelningar. Bpm fungerar som ett paraplysystem, definierar processer och använder sina funktioner för systemintegration utan att användarna märker några förändringar eller försämringar av prestanda. En sammansatt tillämpning hämtar sin funktionalitet från ett antal befintliga källor inom soa för att skapa nya tjänster. Med bpm är det enkelt att bygga upp sammansatta tillämpningar som annars skulle bli för kostsamma eller riskabla att skaffa eftersom man då skulle tvingas att ändra i de befintliga tillämpningarna.
Vilka typer av företagsprocesser är de bästa att använda med bpm?
Bpm-investeringar brukar ge goda resultat (roi) inom följande områden:
- Dynamiska processer. Dynamiska processer ändras ofta, till skillnad från statiska som nästan aldrig ändras. Ett bra exempel på dynamiska processer är sådana som måste anpassas till ändringar i regelverk och liknande – till exempel måste återförsäljare anpassa hanteringen av kundregister efter gällande regler och lagar, men även efter kreditkortsföretagens krav.
- Processer som involverar människor och flera olika avdelningar, affärsenheter, arbetsgrupper eller andra funktionsinriktade grupper av människor.
- Komplexa processer (exempelvis processer för beställning till betalning). Komplexa processer kräver att flera människor från olika avdelningar eller funktioner använder olika program och/eller information för att utföra sin del av processen.
- Mätbara verksamhetskritiska processer – effektivare processer innebär en direkt och mätbar ökning av produktiviteten, inom områden som är viktiga för företagets verksamhet.
- Processer som inte kan slutföras utan data från ett eller flera affärssystem (eller processer som ger viktig extra kapacitet, exempelvis personalfunktioner som de anställda själva kan komma åt).
- Processer med undantag som hanteras manuellt (till exempel en återförsäljare av möbler som förlitar sig på manuell lager- och produkthantering).
- Processer med undantag som kräver snabba åtgärder.
De områden där bpm inte passar är följande:
- Som ersättning för affärssystem
- Transaktionsprocesser vid höga volymer (exempelvis säljsystem, även om försäljning mellan företag kan vara ett bra objekt).
- Processer som inte alls, eller i mycket liten grad, involverar användare.
- Processer som enkelt kan automatiseras till en låg kostnad med andra verktyg.
Ibland är den viktigaste delen av en strategi att veta vad man inte bör göra, speciellt när det gäller relativt horisontella system som bpm. Ett första försök med bpm bör ske med en process som är viktig, men inte den mest verksamhetskritiska på företaget. När bpm utförs på rätt sätt sätts stenen i rullning, om man fokuserar på en specifik och snabb lösning för en synlig förbättring av en process kommer det att kunna medföra större bpm-implementering på bred front.
Det verkar som om alla säljer bpm, men hur ser bpm-marknaden ut?
Leverantörerna har ett brett spektrum av lösningar som är utformade för många olika branscher och behov. På den mest avancerade nivån finns det i stort sett två olika typer av leverantörer, de som erbjuder bpm som en del av affärssystem och de som säljer separata bpm-programsviter. Ibland går det att köpa bpm-lösningar i den första kategorin, separat från affärssystemet, och ibland går det inte. Till exempel innehåller Filenets P8 processkapacitet som bara kan användas som man använder Filenets ECM-lösning, medan SAPs Netweaver-teknik kan användas fristående.
Leverantörer som erbjuder bpm som en del av ett affärssystem brukar erbjuda bpm-funktionalitet som fokuserar på, och utökar affärssystemsarktitekturen. Till exempel kan en leverantör av dokumenthanteringssystem erbjuda dokumentcentrerade bpm-funktioner, medan en leverantör av mellanvara betonar dataintegrationen i sin bpm-lösning. Bpm-funktioner i affärssystem består oftast av tilläggsteknik som köpts in från andra leverantörer och kopplats samman med systemet i fråga, vilket inte borgar för en särskilt stabil lösning. Men givetvis har båda typerna av lösningar sina nackdelar och fördelar.
Nytt på bpm-marknaden är lösningar med öppen källkod. De mest välkända är JBPM från JBoss. De senaste versionerna av JBPM har blivit avsevärt bättre än tidigare, men det saknar många av de funktioner som ingår i plattformar från de ledande kommersiella bpm-systemleverantörerna som Lombardi Software, Pegasystems och Savvion (som inte erbjuder lösningar med öppen källkod). De bpm-funktioner som ingår i JBPM är inte lika stabila som de i de många kommersiella produkter där modellsimulering och utveckling av grafiska användargränssnitt ingår.
Det finns vissa nyckelbegrepp som den som ska välja bpm-leverantör inte bör glömma:
- Kontrollera att leverantörens bpm-plattform är helt integrerad. Vissa leverantörers plattformar har bara byggt "bryggor" till modellerings- och simuleringsverktyg och kallar det bpm. Ibland är rapportverktyget bara ett tillägg. Sådana "fusklösningar" hindrar bara utvecklingen av bpm som ett verktyg för bättre processhantering.
- Låt inte tekniska preferenser hindra en objektiv jämförelse av bpm-systemens funktioner och kapacitet. Att välja bpm-verktyg utifrån om det baseras på Java eller Microsoft Net är inte lika bra som att välja verktyg utifrån de bpm-funktioner som affärsanalytiker behöver för processmodellering eller de funktioner som användarna behöver för att övervaka och utföra sina arbetsuppgifter. Det gäller till exempel att inte falla för den snofsigaste regelmotorn och att inte låta sig hindras av befintlig arkitektur eller befintliga leverantörspartners när man väljer en plattform som ska underlätta processförbättringar i hela företaget. Faktum är att bpm-plattformen bör vara oberoende av begränsningarna i affärssystemen så att man får tillräcklig flexibilitet och kan byta ut grundsystemen utan att påverka automatisering av de processer som användarna kommer i kontakt med.
- Ta alltid en god titt "under huven". Olika leverantörer har mycket olika sätt att implementera grundläggande bpm-funktioner, som exempelvis hur processmodellen länkas till underliggande implementeringar eller hur användargränssnitt byggs upp och integreras i arbetsflödet. Vissa leverantörer ger bättre stöd för ett stort engagemang från affärsanalytikernas sida vid konstruktion av en bpm-tillämpning (som inte kräver avancerade programmeringskunskaper), medan andra kräver en hög nivå på programmeringskunskaperna för de enklaste utvecklingsuppgifter. Vissa leverantörer har väldefinierade och lättanvända gränssnitt som kan anpassas och integreras av användarna för att uppfylla specifika behov. Den som lägger tid på att undersöka tillämpningarna på detaljnivå kommer att förstå exakt vilken leverantörs produkt som kommer att passa in i den egna organisationen och uppfylla företagets specifika behov.
Vad är skillnaden mellan bpm och serviceorienterad arkitektur, soa?
Soa ger tillgång till andra tillämpningar. Bpm använder soa för att inkludera information från dessa tillämpningar i en förbättrad process. Om soa utgör en väg till informationen, så är bpm den funktion som följer vägen genom infrastrukturen för att uträtta användbara saker.
I ett nötskal ger soa möjlighet att skapa tjänster som stödjer affärsprocesser som kan kombineras för en mer flexibel verksamhet. I mer tekniska termer är soa ett ramverk för integration och arkitektur som stödjer löst sammankopplade tjänster och möjliggör integration av nya och gamla affärssystem. Det låter dessa system visa sin funktionalitet för andra tillämpningar på ett standardmässigt sätt. Till exempel kan ett betalnings- och kontosystem tilldelas ett gränssnitt som låter andra tillämpningar att lägga in betalningar i systemet. Med bpm går det att kombinera olika tjänster från olika tillämpningar i nya processer.
Ibland kan en bpm-satsning utgöra startpunkt för en soa-strategi. Vi lever i en värld där företagsledningar vill se resultat av sina IT-investeringar på en gång och då kan soa vara svårt att sälja in eftersom det är svårt att förklara värdet av soa i konkreta och lättförståeliga termer. En strategi för att komma runt detta hinder är att förklara hur soa kan underlätta bpm, eftersom bpm är mer konkret. Det är lätt att förklara vad det är värt att underlätta och effektivisera specifika och verksamhetskritiska processer, och i det sammanhanget kan soa ingå som en del.
Men en av de saker man bör vara medveten om handlar om kvaliteten på de tjänster som kan levereras av de tillämpningar som utgör soa-tjänsten. Det är speciellt viktigt när leverantörerna av dessa tjänster finns på andra delar av företaget eller kanske till och med på andra företag. Tillämpningar som använder sådana gränssnitt måste utformas så att de kan fungera när de externa tjänsterna inte finns tillgängliga. Företaget måste skaffa ett avtal med sina soa-partners som reglerar kvaliteten på de levererade tjänsterna. I sådana avtal bör det ingå överenskommelser om när och hur gränssnitten ska uppgraderas. Saken är den att om man använder soa som en integrationsstrategi för bpm så kommer man att ha verksamhetskritiska affärsprocesser som förlitar sig på dessa tjänster. Om tjänsterna inte finns tillgängliga så kommer de bpm-styrda affärsprocesserna inte att fungera. Därför bör man vara säker på att man kan garantera och kontrollera kvaliteten på alla tjänster bpm-lösningen baseras på.
Finns det några standarder för bpm?
Ja, förespråkare för bpm försöker följa samma väg som andra tekniker lyckats med och vill etablera en solid grund av industristandarder som stödjer fortsatt tillväxt och accepteras av kunderna.
Kunderna är intresserade av standarder eftersom det underlättar för dem att flytta sina tillämpningar till andra bpm-leverantörer, hitta utvecklare och integrera med andra bpm-system och externa partners, och även att minska kostnaderna. Olyckligtvis har den breda funktionaliteten som ingår i ett ordinärt bpm-system och det otal antal intressegrupper som finns enbart resulterat i framväxande standarder för delar av den vanliga ledningsprocessen (design, utförande, underhåll).
De viktigaste standarderna idag:
- BPMN (Business Process Modeling Notation) - fokuserar på grafiska modeller av affärsprocesser.
- BPEL (Business Process Execution Language) – en standard under utveckling som lägger fokus på processutförande och kommunikation mellan system.
- BPML (Business Process Modeling Language) – en xml-baserad programmeringsstandard som bygger på Pi-Calculus och Web Services.
- BPQL (Business Process Query Language) – fokuserar på administration och övervakning.
Det viktigaste att tänka på i det här sammanhanget är att alla dessa standarder (och alla de övriga som inte finns med på listan) bara fokuserar på en liten del av en bpm-produkt. Den stora utmaningen blir att integrera alla dessa standarder i ett kontinuerligt förlopp för processförbättring med bpm.
Finns det då några standarder under utveckling som tillåter överföring av kompletta bpm-tillämpningar mellan olika leverantörer? Nej. Standarder kan i framtiden komma att medföra utveckling av närliggande produkter (exempelvis verktyg för rapportering och analys) som hanterar en del bpm-data, men idag spelar de befintliga standarderna inte någon större roll för bpm-produkter (annat än i marknadsföringssammanhang).
De mest betydelsefulla standarderna idag är finns i områden som är viktiga för bpm, som soa, xml, dokumentationsstandarder och så vidare.
Vad kostar bpm? Vilka är de dolda kostnaderna?
Ett normalt bpm-projekt innebär licensiering av ett bpm-system från en leverantör, utbildning av personalen och att anlita extern hjälp för att komma igång med bpm-satsningen. Precis som för andra programplattformar finns det ett antal olika typer av licenser att tillgå, exempelvis företagsavtal, per processor, per process, per utvecklare, per användare etcetera.
Idag börjar bpm få fotfäste på många stora företag, vilket gör att bpm-leverantörerna siktar in sig på medelstora företag och minskar licensavgifterna för att de mindre företagens budgetar ska klara kostnaden.
En normal implementering med ett av de ledande bpm-systemen kostar mellan 250 000 och 500 000 dollar för att kunna hantera någon av företagets viktigaste processer. Kostnaden inkluderar de två första punkterna nedan.
Potentiella dolda kostnader kan inkludera:
• Licenser till och införande av flera olika utvecklings-, test- och produktionsmiljöer som stödjer flera samtidiga bpm-satsningar.
• Extra program- och serverdatabaslicenser.
• Personal som hanterar och matar in data i servrarna
• Interna kostnader för att få med användarna i processmodelleringen, framtagningen av definitioner för processregler, utveckling av användargränssnitt, test och genomförande.
• Lednings- och utbildningskostnader för att övertyga användarna om det positiva i en övergång från händelsestyrda till uppgiftsstyrda arbetsuppgifter. Händelsestyrda arbetsuppgifter betyder att användarna "vet" vilka uppgifter de ska utföra och i vilken ordning de ska utföras eftersom de alltid gjort så, de prioriterar arbetsuppgifterna beroende på vad som inträffar och när det händer, ofta enligt modellen att det som inte är trasigt behöver inte åtgärdas. Uppgiftsstyrt arbete innebär att den logik som byggts in i bpm-lösningen definierar arbetsuppgifterna samt vilken ordning de ska utföras i och vilken prioritet de ska ha. Användarna övervakar en att göra-lista för att få reda på vad de ska arbeta med.
Vad ingår i implementering av bpm?
På samma sätt som implementering av andra program kräver bpm både verksamhetsmässiga och tekniska resurser och aktiviteter. Effektiv bpm baseras på en kontinuerlig process av design, utveckling och leverans. Även om de vanliga personerna ingår i projektet (exempelvis sponsorer från ledningen, projektledare, användare, analytiker, systemarkitekter, kvalitets- och infrastrukturspecialister) så kan deras roller i bpm-projektet te sig något annorlunda.
Vid en normal implementering av ett bpm-paket hos ett företag finns användarna med på kravspecifikations- och planeringsstadiet. Efter det är de vanligtvis inte involverade alls, förrän det blir dags för användartester. En bpm-implementation kommer de dock att kräva kontinuerligt deltagande från nyckelanvändare på verksamhetssidan och affärsanalytiker när processmodellerna utvecklas och de tillämpningselement som ska stötta dem implementeras i olika steg. Användare på verksamhetssidan och IT-personalen är oftast inte vana vid ett kontinuerligt samarbete för att implementera program, vilket också innebär att planering, utbildning och ledning blir nyckelbegrepp för en lyckad bpm-implementering.
En annan tänkbar utmaning med bpm är det ändrade beteende som krävs av dem som deltar i processen. Ofta kräver bpm att användarna förändrar sättet de utför sina arbeten på, från händelsestyrda arbetsuppgifter till uppgiftsstyrda, de senare styrs av de regler och prioriteringar som finns inbyggda i bpm-systemet.
För många av de anställda kommer bpm att innebära att de kommer att övervaka en inkorg där arbetsuppgifterna levereras med förinställd prioritering och instruktioner för hur de ska utföras, i stället för att utföra de uppgifter som verkar mest angelägna. På vissa företag kommer det att räcka med väl planerad och genomförd utbildning för att klara övergången, men hos andra kan implementering av uppgiftsstyrda arbetsprocesser kräva en större förändring av hela företagskulturen.
10 tankeställare från genomförda bpm-projekt
Gör
Börja med en viktig process som är viktig för företaget.
Undvik
Att försöka fixa till den mest avancerade processen eller att göra allt samtidigt.
Gör
Ta fram ett enkelt räntabilitetsmått för projektet som är meningsfullt för företaget.
Undvik
Att göra för många eller för avancerade mätningar av processutförandet.
Gör
Sluta modellera, börja implementera.
Undvik
Att vänta tills alla är överens om den nya processen innan installation och testgenomförande.
Gör
Insistera på ett iterativt genomförande i flera steg, med olika delmål.
Undvik
Att projektlängden blir alltför flexibel – den första processen bör fungera inom 60 till 90 dagar då det bör finnas en fastställd plan för framtida installationer.
Gör
Använd de egna affärsprocessernas behov vid jämförelse av offerter.
Undvik
Att fokusera för mycket på tekniken eller att tro att alla bpm-system är likadana.
Hur brukar företag organisera sina bpm-projekt? Vem ska ansvara för bpm-satsningen, verksamheten eller IT?
I ett normalt bpm-projekt ingår en sponsor från ledningen, analytiker från verksamhetssidan som har detaljkunskap om processerna, IT-personal som kan ta fram relevanta data och integrera system, samt utvecklare som kan bygga gränssnitt som vägleder användarna genom den nya processen. Konsulter finns ofta med i det första projektet, men målet är att företaget ska kunna klara av framtida bpm-satsningar på egen hand. Bpm-satsningar kräver ofta att personal från olika funktioner inom företaget deltar. Projektgruppen kan likna ett vanligt IT-projekt, med den skillnaden att personal från verksamhetssidan deltar i processmodellering och utformning av gränssnitt.
Bpm kommer oftast in i företaget från IT-avdelningen. Det innebär ibland att IT får huvudansvaret för projektet, speciellt om det är första gången. IT-avdelningens inblandning i alla företagets funktioner passar också bra ihop med den företagsomspännande bpm-kapaciteten. Många företag har skapat interna grupper som arbetar med förbättringar av processer och bpm blir då en naturlig del av ett sådant arbete.
Men bpm är ett sätt att kontinuerligt effektivisera processerna som går utanför det rent tekniska. Kontinuerlig processförändring kräver en ingående kunskap om processerna och vad förbättringar av dem kommer att innebära. Dessutom måste bpm-gruppen ha möjlighet att fatta beslut snabbt. Dessa faktorer gör det mer lämpligt att verksamhetssidan/ledningen leder och driver bpm-projektet och att IT-sidan underlättar, skapar exempel och sköter integrationen mellan system.
Hur får man ledningen att godkänna ett bpm-projekt?
För det första måste man analysera om bpm skulle kunna fungera inom det egna företaget eller om det bara skulle innebära merarbete. Det gäller att komma ihåg att bpm är ett sätt att lösa problem av det slaget och förmodligen kommer att överleva specifika leverantörsplattformar på företaget.
Bpm ger bäst resultat om det används på hela företaget, men det införs oftast för att lösa ett specifikt problem med en process. Sedan sprider det sig naturligt när folk ser internt vilka resultat som kan uppnås och börjar införa bpm i andra problematiska processer. Till exempel brukar den första processen där bpm införs på företag vara personalsystemet.
Fem steg till att få ledningens godkännande av ett bpm-projekt
1. Identifiera tänkbara problemområden eller processer som inte fungerar
2. Välj ut ett par av dem och analysera vilka specifika vinster som kan uppnås med vart och ett. Ställ upp det i tabellform.
3. Skapa en modell för räntabilitet (roi).
4. Lägg fram tänkbara omsättningsökningar, kostnadsbesparingar och fördelar som uppnås genom att vissa kostnader undviks.
Hur mäter och uppnår man räntabilitet (roi) i ett bpm-projekt?
Att lyckas med bpm handlar oftast om att ha enkla affärsmässiga mätpunkter, som exempelvis:
• Mindre antal återlämnade leveranser.
• Mindre tid går åt för hantering av specialbeställningar.
• Mer återbetalningar till företaget vid kredittvister.
• Mer metodiskt slutförande av uppgifter/ökad produktivitet.
• Mindre tid går åt för utbildning av nyanställda.
Om det inte går att identifiera en måttstock som är meningsfullt för dem som ansvarar för verksamheten så bör man förmodligen ta ett steg tillbaka och utvärdera om man verkligen identifierat rätt målprocess för bpm.
Att ha rätt måttstock hjälper också projektgruppen att hålla det som är viktigt i fokus och ledningen engagerad. Eftersom bpm är en iterativ lösning är det extremt viktigt att alla inblandare försöker lösa begränsningarna början och verkligen får lösningen att användas i verksamheten. Mätningar och rapporter om resultat är ett krav, speciellt eftersom det innebär förändringar av det dagliga arbetet för användarna.
Till exempel om förväntningarna på en process läggs upp som arbetsuppgifter på en användarportal, behöver ledningen bara övervaka användningen av och genomströmning på den portalen. Om användarna inte utnyttjar portalen tillräckligt ofta kan bpm-lösningen modifieras så att arbetsuppgifterna skickas via e-post till användarens inkorg i stället för till portalen.
Sammanfattningsvis, för att man ska kunna få ut maximal vinst av bpm krävs det att man:
• väljer rätt målprocesser
• sätter samman rätt arbetsgrupp
• använder en iterativ projektmetodik
• behåller fokus på de affärsmässiga målen för att åstadkomma fler förbättringar och öka användarnas engagemang.
Text: Mark Cooper och Paul Patterson, grundare respektive delägare av Athens Group
Översättning: Lotta Kempe
Den här artikeln har 0 kommentarer:
Molnigt på idg.se?
