Что необходимо знать об IT-системах для функционального и процессного управления

Что необходимо знать об IT-системах для функционального и процессного управления

Анатолий Белайчук Нач. отдела, зам. начальника, Москва

Во многих организациях возможно замечать разобщенность IT-совокупностей. Как лучше интегрировать корпоративные совокупности, дабы не оказался «информационный зоопарк»?

Мы уже поболтали с вами про то, как разделение труда снижает производительность, и про то, как выбрать между ручным, проектным и процессным управлением. Разглядим, какие конкретно существуют инструменты (информационные совокупности) для помощи функционального, проектного и процессного управления.

Начнем с функционального управления. Специальные совокупности – бухгалтерские, складские, совокупности управления жизненным циклом изделий (PLM), совокупности своевременного производственного планирования (APS) и т.п. – обслуживают функции соответствующих подразделений. Исторически такие совокупности показались первыми, как исторически самым ранним есть функциональное управление.

Постановка неприятности

В любой большой организации имеется по крайней мере пара таких совокупностей. Такое положение дел принято ругать, но нужно осознавать, что это не заболевание, а симптом! Разобщенность информационных совокупностей, «информационный зоопарк» – это всего лишь следствие разобщенности подразделений, к которому приводит функционально-иерархическая модель управления.

В случае если руководители и исполнители соседних отделов не смогут договориться между собой и слаженно трудиться в интересах ее клиентов и организации, в случае если процветает местничество, то ясно, что совокупности заказывают под личные потребности, и взаимодействовать между собой эти совокупности будут заведомо не лучше, чем взаимодействуют между собой их клиенты – функциональные подразделения.

IТ-директора пробуют бороться с «зоопарком», но это борьба с симптомами, а не с обстоятельствами, и исходя из этого на полный успех рассчитывать сложно. В случае если в компании процветают феодальные отношения, то начальники отыщут метод и выбить бюджет на «оптимизацию» деятельности собственного подразделения, и израсходовать его на автоматизацию.

Альтернативой узкофункциональным автоматизированным совокупностям являются интегрированные, либо корпоративные совокупности, и прежде всего совокупности класса ERP.

Исторически совокупности ERP показались как следствие эволюции совокупностей планирования материальных и производственных ресурсов (MRP – MRP II), в то время, когда к этим ресурсам добавили ресурсы денежные (бухгалтерию, в широком смысле этого термина) и человеческие (управление персоналом). Это разрешило сказать о комплексном планировании всех ресурсов предприятия, что и зашифровано в сокращении ERP – Enterprise Resource Planning.

Концепция ERP оформилась в начале-середине 1990-х годов, и тогда же показались и реализующие ее программные продукты. В будущем рамки концепции неспешно расширялись, включив взаимоотношение с клиентами (CRM) и поставщиками (SCM), управление ремонтами и техническим обслуживанием и т.д.

С позиций разработок, прогрессу интегрированных совокупностей очень сильно содействовало появление коммерческих реляционных СУБД. Интегрированность корпоративных совокупностей – это прежде всего интегрированность на уровне данных. Несложнее говоря, единая база данных: неспециализированные справочники, отсутствие расхождений между перемещением материальных сокровищ в физическом и денежном измерении (бухгалтерией) и т.п.

И это, само собой разумеется, было огромным шагом вперед если сравнивать с изолированными информационными совокупностями, у каждой из которых «собственная правда», и эти которых не стыкуются между собой.

Но неспециализированные эти – это нужное, но недостаточное условие слаженной совместной работы: нужно позаботиться и о непрерывность потока работ. И такая попытка в рамках ERP была предпринята: по всем канонам, внедрение ERP должно сопровождаться обследованием предприятия, оптимизацией и анализом бизнес-процессов и реализацией их средствами ERP.

Лишь вот незадача: в то время (начало-середина 1990-х) познание того, как нужно руководить бизнес-процессами, очень сильно отставало от современного. Это была эра реинжиниринга – период технократического идеализма:

1) проанализируем отечественные процессы (as-is),

2) спроектируем оптимальный бизнес-процесс,

3) создадим замысел перехода,

4) реализуем его,

5) Profit!

Проект внедрения ERP ложился в эту схему идеально.

Пригодилось приблизительно 10 лет, и многим компаниям было нужно заплатить большую цену, дабы узнать, что эта схема… скажем так – не радует. Обнаружилось глубинное несоответствие: разработчики ERP ориентировались на внедрение совокупности как на однократный проект автоматизации, а бизнес-процессы по природе собственной изменчивы.

Изменчивость эта проистекает из различных обстоятельств: регулирующие органы меняют собственные требования, изменяются глобальная и национальная бизнес-среда, клиенты становятся все более требовательными, соперники изобретают новые методы и подходы, и нам приходится на это реагировать. В данной ситуации компании приходят к выводу, что раз процессы неизбежно изменяются и будут изменяться, стратегически значительно вернее не реагировать на эти трансформации, не предпринимать вынужденные шаги, а самим инициировать трансформации бизнес-процессов, дабы получать тем самым конкурентных преимуществ.

Свойство оперативно поменять собственные бизнес-процессы – это определенная культура в организации, это наличие процессной компетенции и это определенные инструменты, каковые способны в этом помогать. Так вот – стало известно, что ERP в качестве инструмента процессного управления есть скорее пассивом, чем активом.

Разработчики современных ERP совокупностей следовали парадигме реинжиниринга и никак не рассчитывали на то, что настройки совокупности будут довольно часто изменяться. Да, само собой разумеется все ERP-совокупности весьма эластичные, но это гибкость как у цементного раствора: до тех пор пока он жидкий, ему возможно придать любую форму, но в то время, когда он превратился в бетон, то лишь ломом…

Это стало очевидным к началу 2000-х, и в ответ на данный вызов показалась концепция BPM – Business Process Management. Эту концепцию трактуют по-различному, мы в Comindware, придерживаемся трактовки, изложенной в хорошей книге Смита и Фингара «Business Process Management: The Third Wave» (2003). В ней BPM подается как целостный подход к управлению бизнес-процессами в замкнутом цикле моделирование-выполнение-анализ с опорой на новый класс информационных совокупностей – BPMS.

Сокращение BPMS у Смита и Фингара расшифровывается как Business Process Management System, но на данный момент приято ее расшифровывать – Business Process Management Suite, исходя из этого пускай вас не удивляет словосочетание «совокупность BPMS», которое мы будем применять.

Совокупность BPMS разрешает вам обрисовать собственные процессы, после этого добавить к ним модель данных, пользовательские и системные интерфейсы, бизнес-правила и загрузить все это в т.н. «процессных движок», взяв в следствии исполняемую совокупность, которая будет раздавать задания исполнителям (сотрудникам организации), приводить к автоматизированных совокупностей, обрабатывать правила и события и т.п.

Сокровище BPMS в том, что такие совокупности всецело соответствуют современной концепции управления бизнес-процессами: они поддерживают замкнутый цикл проектирование-выполнение-анализ, за которым опять следуют перепроектирование, выполнение и т.д. (По сути это цикл PDCA Деминга).

Совокупности BPMS кроме этого соответствуют правилам маневренной разработки (Agile): маленькие итерации, опора на живой опыт пользователей, динамический список пожеланий по доработке (backlog). Для этого в совокупностях BPMS делается сильный упор на стремительное прототипирование и графическое моделирование всего, что лишь возможно: процессов, данных, пользовательских интерфейсов, бизнес-правил и т.д.

Так, BPM на базе BPMS снабжает органичное единство разработки, принципов и методологии реализации проектов.

Сравнение ERP и BPM как инструментов управления:

ERP

BPM

Методологическая база

Реинжиниринг: as-is/to-be, замысел перехода от текущего к оптимальному состоянию

Постоянное усовершенствование: процессы оперативно изменяются за изменяющимися потребностями бизнеса

Технологическая база

СУБД: моделирование, хранение, поиск данных в единой базе данных, пользовательские интерфейсы к ней, отчётность и запросы

BPMS: моделирование бизнес-процессов, процессный пользовательские интерфейсы и движок к нему, анализ результатов выполнения процессов

Подход к реализации

Водопад (Waterfall) либо Громадный взрыв (Big Bang): однократный проект

Маневренная разработка (Agile): программа, т.е. серия проектов различного масштаба, реализующих как радикальные преобразования, так и эволюционные усовершенствования процесса

Спрашивается: что мешало ERP-вендорам реализовать передовой опыт управления бизнес-процессами в собственных совокупностях?

Теоретически – ничего. И такие упрочнения предпринимались и предпринимаются: в современных предположениях ERP-совокупностей возможно отыскать и средства моделирования процессов, и процессные движки. Но особенных упрочнений в продвижении этих идей клиентам со стороны ERP-вендоров не отмечается.

Дело в том, что создать и включить в состав программного продукта нужные разработки – это меньшинство неприятности, громадная же – в умах клиентов, разработчиков, консультантов (собственных и партнеров).

Если вы в течение двух десятилетий насаждали не только определенную разработку, но и определённый подход и определённую методологию к реализации проектов (см. выше), то легко ли вам будет сообщить «так, сейчас играем по новым правилам!»? Обрадуются ли этому ваши клиенты? Осознают ли вас ваши партнеры?

Так как существующий подход растиражирован в миллионах строчков документации, в тысячах презентаций, сотнях учебных направлений, в типовых уставах проектов и т.д. Не несложнее ли все покинуть как имеется, пока продажи не падают? Похоже, именно это и происходит.

Так или иначе, но факт тот, что прогресс в разработках управления бизнес-процессами отправился не по пути перевода ERP-совокупностей на новую, процессную архитектуру, а по пути создания нового класса ПО – BPMS.

С архитектурной точки зрения, BPMS отличаются от ERP и других корпоративных совокупностей тем, что это – не готовое приложение для конечного пользователя, а платформа – среда, в которой возможно обрисовать собственные процессы и перевоплотить их в исполняемую совокупность, которая будет раздавать задания исполнителям (сотрудникам организации), приводить к автоматизированных совокупностей, обрабатывать правила и события и т.п. С данной точки зрения BPMS подобна СУБД, которая кроме этого представляет собой универсальное средство создания приложений для любой предметной области.

Задача заменить ERP либо другие прикладные информационные совокупности перед BPMS не ставится. Оптимальным есть сочетание тех и других: ERP несёт ответственность за помощь функционального управления, BPMS – за помощь процессного управления. В предыдущей части мы писали, что процессное управление не отменяет, а дополняет функциональное, компенсируя его издержки.

То же самое мы видим и на уровне ПО: не замена, а органическое сочетание и дополнение.

Такое разделение выгодно для обеих сторон.

В случае если взглянуть на опыт внедрения ERP, то мы заметим, что внедрение на уровне бизнес-функций есть задачей прекрасно прогнозируемой и не чрезмерно затратной. Но чем больше в проекте внедрения бизнес-процессов, чем больше их охват и масштаб (чем больше функциональных областей он вовлекает), тем больше появляется сложностей, поскольку изменчивость бизнес-процессов входит в несоответствие с методикой реализации «водопад», – попытками автоматизировать бизнес-процесс, разглядываемыми как однократный проект.

На практике это выглядит так: бизнес-процесс и, как следствие, требования к ПО, изменяются стремительнее, чем консультанты по внедрению и программисты способны их реализовывать при разумных затратах.

Беда проектов внедрения ERP в том, что в «прокрустово ложе» проекта приходится втискивать не только инсталляцию, настройку совокупности, загрузку данных и обучение сотрудников работе с ней – это все задачи прогнозируемые, но еще:

  • организацию совместной работы подразделений в рамках сквозных, кросс-функциональных процессов,
  • поиск оптимальной схемы таковой совместной работы,
  • нахождение компромисса между их руководителями и службами
  • и, в конечном счете, культуры организации и перестройку сознания.

Отдает он себе в этом отчет либо нет, но начальник проекта внедрения ERP-совокупности (в качестве которого в большинстве случаев выступает IТ-директор) борется не с «зоопарком» унаследованных информационных совокупностей – он пробует продавить интеграцию функциональных подразделений и смену функционального мышления на процессное.

Скоро, по приказу это сделать нереально, а продолжительно запрещено – у проекта имеется замысел-сроки и график. Данный конфликт неразрешим, выход из него – избавить ERP от обслуживания процессного управления, сосредоточившись на функциональном. Благо в данной части все ясно, все предсказуемо, и это нужно делать в любом случае, потому что функциональное управление – это фундамент!

Иначе, BPMS идеально подходит для реализации процессного управления, но реализация в нем стандартных бизнес-функций оказывается через чур затратной. Так как как было сообщено выше, BPMS – это не готовый «коробочный» софт, предназначенный для конечного пользователя, а платформа, подразумевающая заказную разработку. А заказная разработка заведомо дороже тиражной. При бизнес-процессов альтернативы нет, поскольку главные бизнес-процессы неизменно неповторимы.

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

Выводы

Итак, оптимальное технологическое ответ для реализации сочетания функционального и процессного управления – это покинуть ERP лишь автоматизацию функций, а кросс-функциональные бизнес-процессы реализовать в BPMS. Наряду с этим, разумеется, появляются задачи интеграции.

Данный текст опубликован в ходе конкурса «Громадная игра-2014» ? литературного состязания авторов, трудящихся в жанре Non fiction. Номинация «Менеджмент». В конкурсе смогут учавствовать авторы, зарегистрированные в Сообществе менеджеров E-xecutive.ru (независимо от срока регистрации), отправившие собственные публикации на content@e-xecutive.ru с пометкой «конкурс Громадная игра-2014» и указанием номинации в поле «Тема письма», либо выложившие их на портал самостоятельно с пометкой «конкурс Громадная игра-2014, номинация такая-то» во время с 10 февраля по 1 декабря 2014 года включительно.

Подробнее об призовом фонде и условиях определите из описания конкурса «Громадная игра-2014».

Источник изображения: pixabay.com

Лекция 7: Процессный подход к управлению организацией


К прочтению:

spacer