Главная

Статьи

Библиотека статей

Методология бизнес-инжиниринга

В последнее время часто возникает вопрос о проведении бизнес-процесс реинжиниринга в связи с проведением внедрения компьютерных систем управления. Более того, как бы считается очевидным , что процесс внедрения должен сопровождаться тем или иным вариантом реинжиниринга. В настоящем материале мы попытаемся как разделить, так и увязать процессы, связанные с бизес-процесс реинжинирингом (БПР) и внедрением АСУ, так и показать взаимосвязи между этими процессами.

Прежде всего, необходимо сказать, что все же БПР и внедрение АСУ есть процессы совершенно различные и ни в коем случае их не следует смешивать. Более того, большинство неудач при внедрении АСУ связаны именно с тем, что перед началом проекта не было четко уяснена его цель, точнее по умолчанию предполагалось, что “создать систему управления” - значит внедрить нечто компьютерное. И в результате - неудача.

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

Как показывает практика - в России совершенно не очевидно. Впрочем, также ясно и почему - гораздо легче сказать - давайте внедрять современную систему финансово-экономического управления (в уме - систему управления как таковую, пишем - компьютерную программу), нежели признаться - “Господа! У нас твориться черт знает что! Давайте разгребем этот бардак!” Хорошо хоть если где-нибудь на заднем плане данное желание присутствует. Гораздо хуже (и гораздо чаще) - реальные запросы никем не сознаются и тем более не формулируются. Неупорядоченные бизнес процессы если не всех, то большинство устраивает (помните пословицу - легче ловить рыбку в мутной воде). В результате - несчастный отдел информационных систем (или как там он называется в каждом конкретном случае) ставится перед проблемой которую не смогли решить высшие руководители предприятия - разгрести управленческие авгиевы конюшни и сделать в них евроремонт. Неслабая задача однако. Неудивительно, что на ней нетрудно сломаться.

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

Для этого нужно, по крайней мере, сделать следующее:

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

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

Обрадовались?

Рано обрадовались!

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

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

• компьютерными
• ручными
• смешанными

Если быть совсем точным, то желательно иметь все бизнес-процедуры в письменном (электронном) виде. Причем не просто текстовые описания, а функциональные модели процедур. Для того чтобы при необходимости изменить частные (отдельные) технологические элементы не пришлось крушить всю процедуру, а можно было мягко подправить компоненты модели, желательно использовать специальные программные средства моделирования. В принципе достаточно иметь средства, которые позволяли бы посмотреть на модель процедуры как бы “сверху”, с тем чтобы можно было бы модифицировать процедуры в их взаимосвязи. Интересно отметить, что такого рода средства либо имеются (например: БААН), либо анонсированы в разработке (например: САП) во всех крупнейших программно-прикладных системах (ППС) для целей управления предприятиями.

Следует иметь в виду, что подобные проблемы имеют место не только в отечественной практике, но и в Западной. В том числе и с этим связаны проблемы с внедрением ППС и на Западе. Правда, там ситуация бывает еще более сложной ввиду того, что на большинстве рынков крайне сложно изменить хотя бы в малости принятые бизнес-процедуры, так как “запас финансовой прочности” компаний часто весьма мал, чего не скажешь про многие отечественные фирмы (было бы что менять - поменять не проблема. Это, конечно, максима, но не так уж далека от истины).

Кроме того, следует иметь в виду еще одну проблему. Она как раз в равной степени характерна и для западных и для отечественных проектов. Быстрая динамика изменений в нашей стране создает иллюзию, что все чуть ли не непрерывно течет и изменяется. В том числе и официальная учетная (здесь и далее в рамках данной статьи, читай - управленческая) практика. Это верно только в том случае если эта практика не связана с управлением бизнесом (что и имело, и пока имеет место в России). Тогда изменить ее ничего не стоит, так как он представляет собой некоторую надстройку над реальным учетом (тем, который назывался и называется “черным”, - припоминаете?). Но вот если на данную учетную практику завязан реальный бизнес, вот тогда ... . Реально вряд ли можно рассчитывать на изменение такого рода бизнес-практики, и, соответственно, связанного с ней учета чаще чем раз в 3-5 лет. Собственно с этим и связано возникновение термина “бизнес-процесс реинжиниринг”. Действительно, постепенно с изменением (развитием) условий бизнеса возрастает неудовлетворенность учетной практикой, в меру того насколько она перестает удовлетворять конкретным потребностям. Но поскольку все устоялось, стало привычным, если не обыденным ... . Как не хочется “уходить в неизвестность”. Первое, что приходит в голову - попытаться провести “ползучую революцию”, или, что тоже, постепенные реформы. Но вполне может оказаться, что конечный и начальный пункты находятся практически в “различных плоскостях” и нельзя “проложить гать” для того чтобы перебраться с одного берега на другой. Хорошо если данная проблем осознается сразу. Но часто даже трудно увидеть “другой берег”, не то, что перейти на него вброд (а если болото?). Конструктивным способом совершить переход в “другую плоскость” (на другой берег) является полный (первичный) отказ от попыток визуально “конструировать мост”. Сначала надо “увидеть цель” (другой берег), и только затем строить планы, как на него перебраться. Действительно, не проще ли арендовать вертолет, чем тащить все на себе по мосту? Собственно, в таком подходе и заключается сущность методологии бизнес-процесс реинжиниринга, в ее классическом понимании.

Кстати, в связи с проектом налогового кодекса возникла проблема, которую формулируют как необходимость ведения специального “налогового учета”. Данная проблем нетипична и даже шокирующая, для Российской практики, так как у нас всегда считалось, что бухгалтерский учет есть однозначное отражение хозяйственных операций и другого и быть не может. В то же время в Западной практике стандартным является получение из одного и того же поля “хозяйственных операций” по меньшей мере, трех отчетов: налогового, официального (акционерного) и управленческого. При этом “финансовые результаты” могут несколько (а возможно и существенно) отличаться во всех трех, особенно в “разрезах по видам деятельности” или “товарам”.

В отечественных условиях несформированных бизнес-процессов и бизнес процедур, не говоря уже о специфической регламентации учетной практики, бизнес-процесс реинжиниринг в оригинальном понимании этого термина практически невозможен (так как реинжинирить нечего). Речь должна идти об инжиниринге бизнес-процедур и бизнес-учетной (и управленческой - напоминаю) практики. Но тут как раз и возможна засада - созданную практику поменять будет нелегко (опять же напоминаю - не следует рассчитывать на это скорее, чем через 3 года). И уж совсем нелогична ситуация - “давайте попробуем”, кстати, помните поговорку - “нет ничего более постоянного, чем временные решения”. И опять вспомните к чему она исторически, как правило, применяется - к неудачным, проблемным (мягко сказать) решениям.

Особая сложность ситуации возникает в связи с тем, что, как правило, продавцы (поставщики) компьютерных систем и консалтинговых услуг, первые - чаще ввиду недостаточной компетентности, но всегда те и другие - ввиду известной поговорки “увяз коготок - птичке пропасть”, не стремятся дать корректное представление потребителю о сложностях которые его ждут. Кстати это относится не только к западным фирмам, но и в той же, если не большей мере, и к российским фирмам - поставщикам. Последние склонны апеллировать к “адаптированности” своего продукта к отечественным условиям, забывая о том, что по статистике процент успешного внедрения сравнимых по сложности программных продуктов также вполне сравним (и часто не в пользу российских “адаптированных” разработок).

Что касается работы консультантов, то здесь есть еще одна существенная проблема. Дело в том, что как уже говорилось, в отечественных условиях, требуется реинжиниринг бизнес процессов, что, как правило, явно не формулируется. Естественно, заказчик про себя рассчитывает, что при внедрении системы данный инжиниринг будет проведен. Но консультант делает только то, что ему было заказано. Если было заказано внедрение, то это означает, что нужно втиснуть существующие бизнес-процессы в рамки системы. Бизнес- процесс реинжиниринг? Пожалуйста, за отдельные деньги, конечно! В результате часто получается плохо.

При внедрении западных систем возникает еще один довольно любопытный аспект. Дело в том, что практически все системы поддерживают технологии управления бизнесом, которые считаются стандартными в Западной практике, например такие, как статистическое управление складскими запасами, планирование потребности в материалах, управление логистическими цепочками и другие. Российская ситуация по отношению к таким системам - это “открытие Америки”. То есть в реально работающих на рынке фирмах, как правило, интуитивно понимают сущность таких технологий, но считают их своим изобретением и не особенно желают вдумываться в открывающиеся в связи с приобретением высококлассной системы возможности, но крайне болезненно реагируют на малейшее несоответствие существующих “оригинальных наработок” (или - “специфических потребностей”, часто нечетко сформулированных) возможностям или особенностям приобретенной (рассматриваемой для приобретения)системы.

Таким образом, теряется значительная доля преимуществ(если не все), которые может получить конкретное предприятие от внедрения современной автоматизированной системы управления.

Так что в заключение можно сказать: “компьютерная система управления не догма, а средство ... достижения конкретных результатов в бизнесе”

Источник: www.bigspb.ru

Коротко о системе Е-МАСТЕР

Е-МАСТЕР® — система управления корпоративной информацией. Е-МАСТЕР® включает в себя возможности систем класса ECM (Enterprise Content Management). Система обеспечивает: Совместное создание и согласование документов Каждый документ может быть обсужден как при помощи прикрепленного к нему мини-форума, так и в главном форуме Разработанный документ может быть направлен на согласование по указанному маршруту Хранение документов любых форматов Хранение и передача документов в зашифрованном виде Встроенные системы восстановления после сбоев и резервного копирования Поиск документов Возможность поиска по ключевым словам и другим атрибутам документов (автор, дата создания…) Возможность поиска с помощью навигации по рубрикам Управляемый доступ к документам Возможность установки доступа к документам для различных категорий пользователей Возможность введения ограничений на работу с документами Функциональный интерфейс пользователя Веб-интерфейс, позволяющий просматривать карточки и скачивать файлы из системы хранения документов Удаленный доступ или работа пользователя из любой точки мира (при условии подключения к Интернету). Подробнее о Е-МАСТЕР >>

Система FLAMORY™

FLAMORY™ — уникальный программный продукт, позволяющий сохранять историю действий пользователя на компьютере, таких, например, как работа в приложениях Windows, посещения сайтов и д.р. Сохраненные последовательности действий, далее, можно просмотреть, сохранить в файл и передать коллегам. FLAMORY позволяет аккумулировать и делиться знаниями. Работая с FLAMORY, обмен опытом, обучение новых сотрудников, обсуждения технологий, становятся, как никогда ранее, простой и удобной, в практических аспектах, задачей. FLAMORY™ разрабатывается при участии специалистов KMSOFT. Скачать бета-версию можно по этой ссылке.

Версия для печати  |  Пользовательское соглашение