Съдържание на статията
Управление на бизнес процесите: колко, как, защо?
стр.2 Процеси, в които участват само хора
стр.3 Автоматизирано изпълнение на дейности
стр.4 Законодателство и самоуправление на SOA организираната система
стр.5 Рефлективност-реакция на външни събития
Всички страници
Управлението на бизнес процесите и системите за тяхното управление, уеб услугите и SOA трайно се настаниха в публичното пространство. Създава се впечатлението обаче, че има разминаване в разбирането на двата аспекта на проблема – оперативният и технологичният.

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

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

 

 

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

В сърцето на всяка BPMS е системата за дефиниране и изпълнение на процеси (workflow engine). На фиг. 1 е показана типичната ситуация. Всичко започва с дефинирането на схемата на бизнес процеса като серия от логически свързани действия. Това се прави чрез специално приложение (workfow designer, workflow architect). Всяка дейност се описва с име, изпълнител, ресурси, параметри и т.н. Изпълнителят може да бъде както човек, така и някаква IT система. Веднъж създадена, схемата на работния процес се записва на BPMS-сървъра като шаблон (workflow). В зависимост от нивото на организацията и сложността на бизнеса в сървъра може да има от няколко десетки до няколко стотици схеми на бизнес процеси. Системата може да пуска множество екземпляри от всеки шаблон. Това са реалните бизнес процеси. Стартирането на нов екземпляр от даден процес може да става както от човек, така и автоматично. BPMS сървърът (по-точно частта workflow engine) следи изпълнението на дейностите от всеки бизнес процес и генерира задачи на различните потребители (хора или други IT системи) в зависимост от логиката на схемата. Крайните потребители работят само с таблица от задачите, които имат да изпълняват. Те изобщо не са ангажирани с това каква и колко сложна е схемата бизнес процеса. Списъкът със задачите се получават от изпълнителите през Интернет: хората използват уеб приложения, а автоматичните задачи се получават чрез извикване на уеб услуги.

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


Процеси, в които участват само хора

Най-простият начин за използване на BPMS както от IT, така и от инвестиционна гледна точка е ако ограничим процесите само до задачи, които се възлагат на хора.

Какво представлява

В този случай BPMS е отделно уеб-базирано приложение с централизиран сървър и достъп до него през уеб браузър. Системата съдържа дизайнер на процеси и сървър, който съхранява схемите и изпълнява отделните процеси. Освен форми за преглед и изпълнение на задачи обикновено се предлагат средства за следене на работещите процеси в реално време, потребителите и справки за всеки отделен процес. Включват се и механизми за обмен на информация между участниците в процесите: е-мейл съобщения, форуми, библиотека за публикуване и обмен на електронни документи, календари.

 

 

Как работи

На фиг.2 сме представили примерен процес за отпускане на ипотечен кредит. След стартиране на процеса първата задача отива на кредитния консултант, който въвежда данните за клиента в базата данни на фирмата. Когато той приключи задачата си, администраторът получава задача да провери дали клиентът (кредитоискателят) има право на кредит. Той може да насочи процеса в две посоки: ако клиентът няма право на кредит, администраторът насочва процеса по лявото разклонение – към “Откажи кредита”. Ако клиентът може да получи кредита, процесът продължава със задача към кредитният инспектор, който трябва окончателно да одобри или отхвърли искането. Тази задача може да продължи по три различни начина: или да се откаже на клиента (тогава пак отиваме към “Откажи кредита”), или да одобри искането (дясното разклонение), или да поиска допълнителни сведения, които кредитния консултант трябва да събере от клиента. Така процесът продължава, докато достигне някое от крайните си състояния: отказ или одобрение и сключване на договор. Виждаме, че всички задачи се възлагат и изпълняват от хора, служители на фирмата: консултантът, администраторът и инспекторът.

В този най-прост случай BPMS се използва само за уведомяване на потребителите за получените задачи и за координиране на дейностите в съответствие със схемите на работните процеси. Потребителите изпълняват същинската работа със средства ИЗВЪН системата. Например консултантът трябва да влезе в корпоративната CRM система и да въведе данните за клиента. Тази система не е свързана по никакъв начин с BPMS.

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

Кога се използва

Тази проста употреба на BPMS е приложима практически навсякъде: при координацията на всички офис и административни дейности, в процесите, свързани с предоставяне на услуги и като първа стъпка към внедряване на по-мащабни BPMS. Автоматизирането на “човешките” процеси е идеална първа стъпка към налагане на процесно-ориентирано мислене в организацията, дисциплиниране на служителите и стимулиране на мениджмънта към формализиране, изчистване и оптимизиране на бизнес процесите.

Необходими инвестиции и IT технологии

Тъй като в този случай BPMS е отделна система и не се интегрира с другите елементи на IT инфраструктурата, внедряването е лесно и евтино. Никакви нови технологии не са необходими. BPMS просто е още едно приложение, което се добавя към IT инфраструктурата без да влияе на останалите елементи (ERP, CRM и др.) и без да ги измества. Прагът на възприемане на такава система е много нисък, защото потребителите работят с един елементарен списък от задачи, а веднага усещат ползата от това задачите им да са събрани на едно място със съответните срокове, приоритети и съпътстваща информация. Голямо удобство създава и обстоятелството, че при отчитане на задачите, всички, които очакват техните резултати се уведомяват автоматично и незабавно. Прехвърляне на информация между различни административни единици и географски отдалечени офиси също е автоматизирана. Тъй като работата със системата е в Интернет среда, възможно е дори включване на потребители, които са извън организацията.

 


Автоматизирано изпълнение на дейности. Интеграция на системите чрез използване на уеб услуги. Service-Oriented Architecture и Enterprise Service Bus

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

Какво представлява

Това означава да накараме някакъв софтуер да свърши нещо без участието на човек (на жаргон казваме “в background режим”). В нашия пример за отпускане на кредит очевидни кандидати за автоматизация са последните задачи: “Обнови данните в досието”, “Открий сметка” и “Стартирай процеса на плащане”. След като кредитът е одобрен и имаме пълна информация за клиента, няма нужда наш служител да се занимава с тези рутинни неща. Много важно е да разберем разликата между задача, изпълнявана от човек и автоматизирана задача. Когато BPMS активира една задача, изпълнявана от човек нормално се случва следната поредица от събития:

  • BPMS поставя задачата в списъка със задачи на потребителя. Нека за пример това е задачата “Обнови данните в досието на клиента”
  • потребителят проверява списъка със задачи (това може да стане след неопределено време, например чак на следващия работен ден)
  • той решава да изпълни задачата (също след неопределено забавяне)
  • изпълнява задачата извън BPMS. В нашия пример:
    • влиза в друго приложение (например CRM)
    • намира необходимия запис (клиента)
    • въвежда новата информация
  • връща се в BPMS и отбелязва задачата като завършена (също след известно време)
  • сега вече BPMS може да продължи процеса нататък.

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

Как обаче една софтуерна система (BPMS) да накара друга софтуерна система да свърши нещо?

Как работи

Как работи системата, ако човек изпълнява задачата “Обнови данните в досието”? Както описахме по-горе, потребителят ще влезе в системата с досиетата на клиентите (нека да я наричаме CRM), ще избере необходимия клиент (по клиентски номер, име или ЕГН), ще въведе данните за новия кредит и ще даде командата “Запази”. За да може BPMS да накара CRM да извърши тази операция, трябва самата CRM да предоставя тази функционалност във вид на уеб услуга (web service). Уеб услугите представляват софтуерни компоненти, които реализират някакъв мрежов интерфейс (т.е. могат да бъдат активирани през мрежата – LAN или Интернет) чрез който други мрежови компоненти могат да се свързват с тях и да им пращат данни и команди, както и да получават резултати. Тука няма да дискутираме конкретните технически параметри на свързването (протокол, формат на данните, права за достъп...). Ще кажем само, че езиците за описание и комуникация с уеб услугите са строго дефинирани и стандартизирани. Всяко бизнес приложение (ERP, CRM, BPMS...) публикува своите уеб услуги в специален регистър, откъдето останалите приложения могат да прочетат как да се свържат с него, какви данни да поставят в заявката и какъв резултат да очакват. Например ERP може да предостави уеб услуги, които да променят определено складово количество, да изчислят себестойността на даден детайл, да изготвят заявка към доставчик и т.н. Имайки на разположение тези услуги дизайнерът на бизнес процеси може да ги определя като изпълнители на отделни задачи в схемата на процеса. Така се създават автоматизирани задачи. Когато конкретният бизнес процес стигне до такава задача, вместо да я постави в списъка на някой потребител-човек, той извиква съответната уеб услуга като предварително форматира данните, които са и нужни в съответния формат. Може да има напълно автоматични бизнес процеси, които след като бъдат стартирани изобщо не изискват намеса на човек. Най-често обаче бизнес процесите са смесени – включват както автоматични, така и персонални задачи.

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

Начинът на проектиране на софтуерни системи базиран на предоставянето на уеб услуги се нарича Service Oriented Architecture (SOA).

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

Публикуването на уеб услугите на различни приложения позволява на другите приложения да ги използват за свои цели. Създава се впечатлението, че всички бизнес приложения са свързани в една обща информационна магистрала, по която те могат да взаимодействат едно с друго по предварително зададени алгоритми (чрез схемите на работните процеси) без намесата на човек-оператор като си обменят информация, съобщения и команди. Този образ е добил популярното наименование Enterprise Service Bus (ESB). “Физическият носител” на ESB е системата, в която уеб услугите се регистрират и от която потребителите на услугите получават информация къде какви услуги има, какъв е форматът на входните данни и на резултатите и т.н. Самата концепция на SOA изтрива границите между отделните приложения. Дизайнерът на бизнес процесите разполага с пълен списък на услугите и тяхната функционалност, без да се интересува кое точно приложение предлага всяка конкретна услуга.

Кога се използва

Интеграцията на BPMS с останалите бизнес приложения на основата на уеб сервизи и ESB има смисъл винаги, когато това е технически и технологично възможно! По-точно, интеграцията е желателна, когато потребителите използват други системи (освен системата за управление на задачите си) за да изпълнят работата си. На практика всеки бизнес използва различни корпоративни софтуерни системи.

Извеждането на операции извън затворените рамки на едно бизнес приложение и публикуването им като уеб услуги позволява на дизайнерите на процеси изключителна гъвкавост при моделирането на бизнеса. Можем да направим следната аналогия: както обектно-ориентираното програмиране позволи на програмистите многократно използване на един и същ програмен код (code reusing), така SOA позволява на дизайнерите на бизнес процеси многократно използване на една и съща бизнес логика. В този смисъл SOA представлява истинска интеграция на различните бизнес системи: от отделни затворени бизнес логики те се превръщат в съвкупност от общодостъпни бизнес компоненти, с които дизайнерите на процеси могат да изграждат сложни приложения без нуждата от програмиране, само със средствата за бизнес моделиране, предоставяни от BPMS. Това води до качествен скок в ефективността на работа на организацията. Хората се освобождават от рутинни дейности като едновременно с това рутинните дейности се изпълняват моментално – компютрите работят по 24 часа на ден без почивка и отпуска. По този начин единствените забавяния в изпълнението на бизнес процесите са там, където се намесват хората или в дейностите, които се изпълняват извън интегрираната система.

Необходими инвестиции и IT технологии

За да можем да изградим една изцяло интегрирана система, управлявана от BPMS, необходимо е всички нейни компоненти да са изградени на принципа на предоставяне на уеб услуги. За съжаление това далеч не винаги е така. SOA е сравнително нова концепция и затова само последните версии на най-развитите бизнес системи я поддържат при това на цени, които малцина могат да си позволят. Определено българските производители на бизнес софтуер са големи длъжници на своите клиенти в тази посока. Друг голям проблем у нас са много малкото подготвени консултанти за проектиране на интегрирани системи, базирани на уеб услуги. Самата концепция SOA променя радикално правилата за планиране и стиковане на различните бизнес приложения. Нужна е сериозна промяна в мисленето, целите и “хоризонтите” за да може получената интегрирана система да оправдае големите капиталовложения. Въпреки, че чисто формално SOA просто добавя един нов слой в “технологичния стек” концептуално промените трябва да са много по-дълбоки за да реализират огромния потенциал, заложен в самата идея.

 


"Законодателство" и "самоуправление" на SOA организираната система. Business Rules Engine (BRE)

За да можем да реализираме сложни, многовариантни процеси трябва да разполагаме с механизъм за избор на различни алтернативи. При задачите, изпълнявани от човек това е самият човек – той избира как да продължи процесът на основата на собствената си преценка. При автоматизираните процеси тази задача се изпълнява от системата за управление на бизнес правила (Business Rules Engine – BRE). Това е втората най-важна част на BPMS (заедно с workflow engine).

Какво представлява

Системата от бизнес правила задава условията за избор между различните алтернативи в един процес. Концептуално всяко бизнес правило представлява някакво логическо условие и действия, следващи при различните резултати от проверката му. Например можем ада имаме правило “Ако един клиент има отпуснат кредит по даден имот, той не може да получи втори”. Или “Ако един клиент не е собственик на даден имот, той не може да поучи кредит”. Това ни дава идея, че можем да автоматизираме и задачата “Потвърди собствеността” като приложим последното правило и ако резултатът е отрицателен (клиентът не е собственик на имота), направо да отидем към отказване на кредит. Също можем да добавим нова автоматизирана задача, която да проверява правилото за втория кредит.

Кога се използва

BRE е необходима винаги, когато изграждаме интегрирана SOA базирана система. Без бизнес правилата не можем да въведем решаваща логика в бизнес процесите, което ни ограничава силно в разработването на автоматизирани бизнес процеси. Самата идея за изваждане на бизнес правилата в отделен слой, извън конкретните приложения, създава огромна гъвкавост при прилагането им. Както знаем, основно качество на BPMS е възможността схемите на бизнес процесите да бъдат променяни в реално време без забавяне и без нужда от допълнително програмиране. Възможността да променяме бизнес правилата в реално време и без промяна на схемата на бизнес процесите дава допълнителна гъвкавост на логическо ниво. В нашия пример ако решим да променим правилото за собствеността върху имота (например да позволим да се иска кредит върху имот, собственост на пряк роднина), ние само ще променим правилото и начина, по който се изчислява, но задачата “Потвърди собствеността” няма да се промени. Всъщност целият процес “няма да разбере”, че правилото е променено.

Необходими инвестиции и IT технологии

Системата за управление на бизнес правилата грубо се състои от две части: дизайнер на правила, където правилата се дефинират и BRE, който прилага правилата по време на изпълнение. Най-често и двете части се “представят пред света” във вид на уеб услуги и са части от BPMS. Нищо допълнително не е необходимо.

 


“Рефлективност” - реакция на външни събития. Event-driven architecture

Всяко живо същество притежава способността да реагира на външни събития. Почти всичко, което правим е не защото така ни е хрумнало, а като реакция на някакво външно събитие. Същото е положението в бизнеса. Ние отговаряме на запитвания от клиенти, попълваме запасите си, когато намалеят, подготвяме се за участие в мероприятия на точно определена дата... Хубаво би било нашата автоматизирана и интегрирана IT система да реагира сама поне в някои случаи. Например:

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

Какво представлява

Event-driven Architecture е концепция, според която системата трябва да реагира на всяко значимо за бизнеса събитие. Събитията могат да имат както позитивен, така и негативен ефект върху бизнеса. Реакциите могат да бъдат както просто информиране на съответни отговорници, така и активни действия: отделни операции или стартиране на процеси. Според характера си събитията се делят на два вида: нотификации и таймери. Нотификациите са инцидентни събития. Те възникват случайно и еднократно. Пример за това е запитване на клиент. Таймерите са периодични събития, които възникват по определена схема във времето. Плащането на заплати е такова събитие. Според мястото си на възникване събитията могат да бъдат вътрешни и външни. Вътрешните се предизвикват от ежедневната дейност на фирмата и се съобщават на системата от някоя от интегрираните бизнес системи, например ERP. За външните събития трябва да се създадат специални “сензори”. Това могат да бъдат уеб форми, които клиентът попълва, електронни магазини, специални и-мейли за поддръжка и т.н. Инициативата “електронно правителство” е един голям и сложен пример. Но “сензорите” могат да бъдат и уеб услуги, публикувани на общодостъпно място. Това е “покана” на външни приложения да се възползват от нашите услуги. Примери за това са Google Maps, услугите за онлайн данни на Reuters и Bloomberg, системите за Интернет разплащания и др..

Кога се използва

Винаги, когато е възможно! Event-driven архитектурата създава бързина на реакцията. Хората (като основен източник на забавяне) се освобождават от още една грижа. Не можем да се надяваме, че телефонните обаждания съвсем ще отпаднат, но можем да разчитаме, че поне една част от запитванията и транзакциите ще се обработват автоматично. Таймерите ни освобождават от грижата да помним рутинни периодични дейности.

Необходими инвестиции и IT технологии

BPMS + BRE комбинирани с уеб услугите интегрирани в ESB са достатъчни за покриване на вътрешно генерираните събития. За външните събития обикновено се налага да се напишат прости отделни приложения (например уеб форми), които после се интегрират в общия оркестър на уеб услугите. Таймерите обикновено имат собствен сървър (част от BPMS), но могат да се използват и вградените във всяка операционна система Scheduler-и.

 

Мащабируемост отвъд границите на организацията. Business-To-Business Integration

Коментарът, че автоматичната реакцията на външни събития може да бъде оформена като уеб услуга, описана в публичното пространство ни подсказва идеята на следващия етап на разширението – публични уеб услуги. Ние позволяваме на нашите партньори да се възползват от функционалностите на собствените ни бизнес системи и директно да свържат своите системи с нашите. По такъв начин нашата Enterprise Service Bus преминава границите на организацията ни и се съединява със съответните информационни магистрали на нашите партньори. Естествено за да стане това сливане трябва организациите да са на едно ниво по отношение внедряването на SOA и интегрирането на системите чрез уеб услуги.

Трудно е накратко да се опишат ползите от това. Ще получите идея за какво става дума ако си мислите в термините на елиминиране на човека като междинно звено в предаването на информация от фирма към фирма. Ето още една неявна полза от преминаването на SOA – ще правим по-лесно бизнес с партньорите, които са толкова напреднали като нас.

Необходими инвестиции и IT технологии

Куриозно, но за да стане B2B интеграцията трябва да инвестираме не само ние, но и нашите партньори. Задължително и двете страни!

 

Къде остана човекът, все пак?

След като в началото видяхме какви ползи имат потребителите от въвеждането на BPMS, по-нататък ние постепенно отнемахме на хората все повече и повече дейности. Какво в края на краищата ще правят хората при наличието на една такава автоматизирана и интегрирана система? Не трябва да се заблуждаваме – човекът във всички случаи остава най-важната част от информационната система! Най-важните дейности остават за хората-потребители.

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

Освен това, колкото и странно да звучи, някои от най-важните дейности в една бизнес организация лошо се вписват в схеми на бизнес процеси. Това са дейностите по стратегическото управление и дейностите, свързани с преговори. В такива “творчески” ситуации процесите не помагат много. Тука на преден план излизат други IT функционалности: Business Inteligence, системи, подпомагащи споделянето на информация (места за съобщения, форуми, блогове, конферентни средства), система за съхранение и организация на документи. Това са начини да се подпомогне човека при вземане на решения. В края на краищата най-много време губим докато вземаме решения. Разбира се вездесъщата SOA е приложима и в тези случаи.

Йордан Николов

Виж оригинала