По време на моята кариера съм направил доста реинженеринг на бизнес процеси и най-големият проблем, който намирам, е винаги един и същ: бизнес процеси с отворен цикъл. Процесите с отворен цикъл се случват най-вече, защото отговорността е разделена на множество хора и често между множество отдели. Информационен поток, който започва в научноизследователската и развойна дейност с искане за ново оборудване, може да премине през Финанси и закупуване, преди да излезе извън организационните граници до Доставчика (където той ще премине през няколко отдела на свой ред), и след това обратно към Получаване и , с късмет, R&D групата, която инициира потока.

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

Open-Loops може да струва милиони долари

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

Еднопосочна комуникация между областите на отговорност

Както всички големи организации, отговорностите бяха в силози. Някой в ​​Производството се нуждае от оборудване X, така че информира финансите и се генерира поръчка за покупка (PO). Поръчването изпраща поръчката на доставчика. До една година в бъдеще X се доставя и приема от получателя. Получаването известява Производството и финансите. Финансите издават етикет на актив, който Получаващ шамар върху X. X се поставя в производствената линия и всичко е наред.

Освен всичко не е добре. Като начало служителите идват и си отиват и е лесно да поръчате X, без да осъзнавате, че някой друг в същата роля е поръчал X преди девет месеца. Finance няма представа, че тази поръчка е дубликат: Предполагат, че просто се нуждаете от друг X и така се генерира друг PO и се прави друга поръчка. Отделно от това, дори ако не случайно прекалите поръчката, бързо губите представа за това, което имате.

Да приемем, че X е сложно оборудване, може би линия за запълване. Състои се от 20 основни компонента, всички от които ще бъдат заменени многократно по време на експлоатационния му живот. Етикетът за актив, ударен случайно върху една част от X, ще изчезне поради износване. Още по-лошо, маркерът на актива може дори да не бъде приложен, защото не достига до Получаване навреме. След това никой няма представа как да следи X и следователно няма представа как да го изведе от експлоатация в края на живота си. От данъчна гледна точка X все още е функционираща данъчно облагаема позиция.

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

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

Създаване на двупосочни информационни потоци

Ето как се справихме с проблема. Моделирахме всеки значителен процес от началото до края. Идентифицирахме всички отворени цикли. След това разработихме прости начини за затваряне на тези цикли, един по един, започвайки от самото начало.

Първа стъпка

Производството се нуждае от X, така че те искат от финансите да отворят PO. Финансите вече проверяват с Производството, за да потвърдят, като предоставят подробности за предишни поръчки за X от 24 месеца назад. Случайното дублиране на поръчки се избягва.

Стъпка втора

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

Стъпка трета

Получаването уведомява финансите, които уведомяват производството. Поставянето на маркери на активи се извършва от отговорна страна от Производството, за да се гарантира, че всеки етикет е поставен върху правилния си компонент. След това всички маркери / компоненти се потвърждават за двата ERP модула.

Стъпка четвърта

Всеки път, когато компонентът се замени, Производството информира Finance и нов маркер на активите за този компонент се генерира и поставя върху новия компонент от Производството и след това се потвърждава в двата ERP модула. След това финансите започват процеса на премахване на стария компонент от книгите, докато производството преминава през процеса на извеждане от експлоатация на Ръководството за добри практики (GMP). В края на извеждането от експлоатация Производството информира Finance, за да може активът да бъде изваден от счетоводството.

Подробностите са малко по-сложни от този опростен пример, но въпросът е ясен: На ​​всеки етап по пътя има изрични проверки и потвърждения.

Осигуряване на извънредни действия

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

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

препоръчителен размер на екип за схватка

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

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

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

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

Потвърдете ключови събития

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

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

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

Процедури за обработка на изключения при проектиране

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

всичко Финансиран от NIH изследователските институти съдържат много отделни лаборатории, всяка от които се ръководи от главен изследовател (PI) и в която работят различни подчинени учени и постдокументи. По някое време PI се нуждае от нова тава с многокамерен реагент, така че те искат от един от пост-документите да създаде необходимата заявка. Post-doc създава заявката и я изпраща по имейл до Finance, за да поиска да бъде повдигната поръчка, като копира PI, за да се увери, че PI е наясно, че заявката е изпратена. Междувременно PI има автоматично автоматично известие за календар, което им напомня да проверят състоянието на заявката, ако не са получили потвърждение до определена дата. Това гарантира механизъм за безопасност в случай, че пост-докът забрави да създаде или изпрати необходимата заявка.

Сега пост-докът също има автоматично известие от календара, за да се регистрира във Finance, ако не получи потвърждение за повишаване на поръчката в рамките на определен период от време. Когато Finance вдигне поръчката за поръчка, пост-документът получава потвърждение по имейл, че е изпратено до доставчика, а пост-документът препраща това потвърждение към PI.

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

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

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

Да се ​​научим да създаваме процеси от затворен цикъл от SQL

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

Разбиране на основите

Какво е пример за процес с отворен цикъл?

Пример за процес с отворен цикъл е попълнена заявка без потвърждение до съответните заинтересовани страни. Ако заинтересованите страни не бъдат информирани за попълнена заявка, това създава възможности за неразбиране на съобщенията.

Какво представлява процесът със затворен цикъл?

Процесът със затворен цикъл е такъв, че всички действия, изисквани от процеса, се извършват и всички заинтересовани страни се информират в подходящ момент за приключването на тези действия.

Какво представлява информационният поток в една организация?

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

Как протича информацията?

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

Какво е анализ на информационния поток?

Анализът на информационния поток е акт на анализ на това как информацията протича в дадена система. Този анализ може да помогне за подобряване на информационния поток в бизнеса.