Документиране на бизнес процеси – как и защо?

диаграма на бизнес процес/bpm diagramВъв всяка организация съществуват различни бизнес процеси. Както стана въпрос в статията „Ах, този контрол“ всеки бизнес се нуждае от контрол, но преди да говорим за контрол трябва да определим бизнес процесите. Начинът на описание и документиране на процесите може да има най-различна форма и зависи от опита на съответния методолог, от наличните софтуерни и други технически решения, както и от вида на процесите и лицата, които ги изпълняват (например процес за производство на болтове е много по-различен от процес за одобрение на плащания).

Документирането на бизнес процес се изразява в две направления:

  1. Описание и документиране на типов процес
  2. Документиране на изпълнение на конкретен иницииран (стартиран) процес

 Защо документирането е важно?

Описанието и документирането на типов процес позволява да се опише в документ актуалното познание на организацията за процеса, да се анализира процеса, да се отстранят всички неточности и да се подобри. Следващата стъпка е версия на процеса, която става утвърдена за компанията, да се сведе до знанието на всички заинтересовани, което позволява съответният процес да се изпълнява по един и същи стандартизиран начин от всеки служител. Също така, когато процесът трябва да се имплементира например в софтуер, описанието ще е основа на софтуерния имплементатор за успешното му внедряване.

Документирането на изпълнението на конкретен стартиран процес е много важен елемент, който позволява контрол на системата. Например плановите одити ще търсят съответните документи и доказателства за начина на изпълнение на процеса и ще ги съпоставят с типовия процес.

Описание и документиране на типов процес (шаблон на процес)

През 2004 г. беше публикуван стандарт за Модел на бизнес процеси и система за графично визуализиране (BPMN). Стандартът подробно описва елементите на процеса, начинът на визуализирането им и връзките между тях. Също така беше създаден и програмен език (BPEL), чрез който описанието на бизнес процес можеше стандартно да се изпълни от компютър, като в крайна сметка BPMN и BPEL целят непрограмисти (например методолози, мениджъри) чрез подходящо софтуерно приложение да моделират сами бизнес процеси без да ползват услугите на програмисти и имплементатори. Всичко това според мен са много усилия, направени от екипи от специалисти, хвърлени на вятъра. Въпреки, че BPMN дава добра представа за структурата на процесите, в целия си вид е прекалено тежък за прилагане и успоредно с това не е всеобхватен, а BPEL не може да се конкурира с нито един сериозен програмен език. Разглеждал съм много BPM софтуери, които твърдят, че непрограмист може чрез BPM дизайнер (това е приложение към BPM софтуера за графично моделиране на процеси) да моделира и създаде бизнес процес и мнението ми е, че без намеса от програмист не се създават сериозни модели, които да отговорят реално на нуждите на компанията. Това е така, тъй като процесите са толкова разнообразни, колкото е разнообразен живота и на този етап един BPM софтуер (базиран или не на стандарт) не може да опише всичко. От друга страна обаче чистото програмиране на процес напълно може да опише всичко, но тук непрограмист не може да се справи.

В практиката си аз използвам малка част от BPMN за описание на бизнес процесите и нищо от BPEL. Заменил съм BPEL с PHP и Java Script в моите уеб приложения.

Като начало, обикновено процесите се описват в документи, наричани “процедури”. Процедурите съдържат един или повече от един процес със сходни характеристики. Решението кои процеси да попаднат в една процедура се взима от методолога.

В рамките на процедурата се указват общи правила за изпълнението на процесите, а към всеки процес може да се посочат и конкретни правила. Определянето на момента на стартиране на процеса е важен елемент. Процесът може да стартира както при възникване на определена дата (например всеки вторник – в този случай знаем точно кога ще стартира), така и при възникване на някакво събитие (например, когато клиентът подаде оплакване – в този случай не знаем точно кога ще стартира и е необходимо да “уловим” събитието, когато възникне).

Съответно в зависимост от техническата обезпеченост в компанията, процесът може да стартира ръчно или автоматично. Инициирането на процеса може да се извършва и с предварително дефинирана повтаряемост (това е валидно за процесите, които стартират при възникване на определена дата – например на всяко 3-то число на месеца).

Всеки процес се състои от етапи (можем да ги наричаме задачи). Всяка задача събира в себе си група от задачи (обикновено една задача събира в себе си задачи, при които изпълнителят и времето за изпълнение съвпадат) и трябва да отговаря на следните въпроси:

  • Кой – кое е лицето, изпълняващо задачата. Обикновено изпълнителите се описват с роли, тъй като в роля могат да попаднат лица от различни длъжности и по този начин лесно се преодоляват недостатъците на описанието по отдели и длъжности. Задачата може да бъде изпълнявана както от едно лице, така и от повече лица едновременно. Ако компанията има по-сложна структура и например са налични няколко обекта, за които процесът се стартира отделно, независимо че е един и същи, обектът се явява допълнителен критерий за това на кого да се постави задачата (например процес продажба на стока, който се изпълнява във всеки от 8-те магазина отделно). Ако процесът е софтуерно имплементиран, може да съществуват задачи, които софтуерът самостоятелно автоматизирано изпълнява (например да копира информация от едно на друго място, да изпрати имейл или съобщение, да стартира друг процес и др.).
  • Какво – това е същността на задачата. Т.е. описват се детайлите по изпълнението на задачата. Колко подробно да е описанието се решава от методолога (както се шегувам понякога, описанието дори може да се сведе до “…вдишвам, хващам молива, издишвам, премествам си ръката към бележника, вдишвам, започвам да пиша първата буква, издишвам…”, въпреки че от подобно описание в същност няма никакъв смисъл). За мен критерий за това колко детайлно да опиша задачата е нивото на познание в компанията по съответния проблем, който се решава. Ако смятам, че дейностите са популярни, обикновено описанието е по-общо и обратно, ако са непопулярни, описанието е по-подробно. Целта на задачата е правилно да навигира изпълнителя. Понякога използвам и друг подход: например когато процесът е със софтуерна имплементация, вместо да представям подробна информация, само индикирам какво трябва да се направи, а останалото го “скривам” под info-бутон, натискането на който води до отваряне на подробна информация. По този начин по-опитните служители не се ангажират с четене на ненужни текстове, а по-неопитните имат възможност да направят справка за начина на изпълнение. Тъй като в рамките на една задача е възможно да има различни случаи на изпълнение, при софтуерни имплементации ненужните текстове и разклонения не се показват с цел да не се натоварват изпълнителите.
  • Къде – указва се мястото, където се изпълнява задачата.
  • Кога – начална и крайна дата на изпълнение и при какви условия възниква (т.е. на коя дата, при какво събитие, дали трябва да са изпълнени други задачи, при какъв резултат на изпълнение на предходни задачи и др.)

Всяка организация трябва да вземе решение наборът от задачи, които се изпълняват в кои процеси попадат. Случвало ми се е да стартирам с един процес и практиката да покаже, че е по-удобно да се раздели на два отделни процеса, вторият от които се стартира от първия, но при определени условия.

Всяка промяна в процеса се документира с нова версия. Компанията трябва да има ясна политика какво се случва с вече стартирани процеси, чиято версия се сменя – дали продължават по старата или по новата версия. Моята политика е стартираните процеси да се приключат по старата версия, но допускам, че в определени системи и процеси това може да не е правилно.

Процесите могат да бъдат допълнително обезпечени с Инструкции и други подобни документи, които обикновено представят специфични ситуации.

Имплементиране на бизнес процес

Имплементирането на процес е конкретно настройване на системата за работа с процеса. В рамките на една компания различните групи процеси могат да се имплементират по различен начин. Например административно-управленските процеси могат да бъдат имплементирани в софтуер, който поставя задачи (за изпращане на оферта, одобрение на плащане, преглед на договор и т.н.) или в който се адаптират бизнес правилата, така че софтуерът да води служителя по точните стъпки без това да са изрично поставени задачи (например стока не може да излезе от склада, ако не е платено и не е издадена складова разписка, фактура не може да бъде издадена, ако не е получено потвърждение от клиента за получена стока или фактура от доставчик не може да бъде осчетоводена, ако стоката не е постъпила в склада, което се удостоверява от отговорно лице с изричен запис в ERP системата). Производствените процеси например могат да бъдат имплементирани както чрез графично описание на производствения цикъл, който се отнася до съответния изпълнител и детайл, така и чрез специфични технически настройки на машините и оборудването. За имплементиране на процесите могат да се използват също хартиени и електронни чек листове, уеб форми, имейл съобщения (не препоръчвам имейлите за това), задачи инициатори и др. подобни разновидности.

Софтуерните и технически имплементации значително ускоряват изпълнението на процеса, намаляват дублирането на информацията, ускоряват своевременната информираност на заинтересованите служители за етапите на изпълнение, намаляват грешките (чрез различни модели за валидация на информацията) и като цяло увеличават съществено качеството на изпълнение на процеса, което директно води до по-качествени стоки и услуги и по-доволни клиенти и служители.

Документиране изпълнението на конкретен иницииран процес

След като стартира конкретен процес, изпълнението на всяка задача води след себе си и документална следа на изпълнението на процеса.

Както вече уточних, в зависимост от опита на методолога, техническата и софтуерна обезпеченост в компанията, както и от вида на процеса, документирането може да се осъществи по различни начини.

Например ако процесът не е имплементиран софтуерно, компанията може да използва хартиени чек листове. Ако процесът не предполага използване на чек листове, компанията може да го представи графично или текстово на съответните лица и да изисква от тях да го познават и спазват. В първия случай всяка  стъпка в процеса се проследява от чек лист и реално изпълнителят бива подпомагат от чек листа при изпълнение на процеса, докато при втория случай, изпълнителят текущо няма изричен документ, чрез който изпълнява процеса и може да ползва методологията, описана в съответната процедура.

Ако е направена софтуерна имплементация, чек листът може да се замени с уеб или друг вид форма, в която изпълнителят попълва резултатите от изпълнението и която указва на изпълнителя какво да прави. Ако уеб формата не е удобен начин за съответния процес, процесът може да се имплементира в съответната ERP или друга система и самата система да води изпълнителя според начина, който е заложен при внедряването (например за процес продажба на стока, ERP системата изисква издаване на складова разписка, отразяване на плащане и последващо издаване на фактура и изпращане по имейл).

Независимо от начините на документиране на изпълнение е необходимо да има “следа”, която да показва как е изпълнен всеки конкретно иницииран процес. “Следа” са всякакви документи, записи и друг вид информация, която се генерира при изпълнение на процеса. “Следа” са чек листовете, издадените фактури и складови разписки, офертите и договорите, протоколите за извършен оглед или извършена услуга, направените записи в съответния регистър, изготвената заповед, резолираната заповед, протоколът за заприходяване на готовите болтове и всички други хиляди вариации на документи и информация, които могат да послужат за доказателство за изпълнение на процес.

Публикувано в Бизнес, Бизнес процеси, Софтуер с етикети , , , , , , , , . Постоянна връзка.

Вашият коментар