| СТАТЬЯ |
18.04.03
|
© Дмитрий
Слиньков,
КОРУС Консалтинг
© Статья была опубликована на сайте
Не стоит планировать весь процесс внедрения ИСУ предприятия в рамках одного контракта. Начните с малого: заключите контракт с поставщиком или с консалтинговой фирмой на стадию бизнес-моделирования. Бизнес-модель — это осязаемый результат, с помощью которого можно максимально определить важнейшие параметры проекта
Мастерство — это когда «что» и «как» приходят одновременно
В. Э. Мейерхольд
Любой проект внедрения ИСУ (интегрированной системы управления) предприятия состоит из двух этапов:
Рис. 1
Поэтому, чтобы получить оптимальное решение, способное принести практическую пользу и вместе с тем приемлемое по стоимости, лучше не рассматривать проект внедрения ИСУ как единый контракт — от обследования до ввода в промышленную эксплуатацию интегрированной системы по всем участкам предприятия. Начните с малого: заключите контракт с поставщиком прикладного пакета для построения ИСУ или с консалтинговой фирмой исключительно на стадию бизнес-моделирования. Ни в коем случае не ограничивайтесь «только обследованием» и прочими не целостными способами решения ваших проблем. Бизнес-модель — это осязаемый результат, с помощью которого можно максимально конкретизировать цели внедрения ИСУ предприятия и определиться со следующими параметрами проекта:
Конечно, создание бизнес-модели — процесс не быстрый и занимает обычно от четырех до девяти месяцев. Главное — набраться терпения и получить ответы на давно назревшие вопросы. Естественно, если речь идет о локальной автоматизации бухгалтерского учета, то результата можно добиться быстрее. Однако при комплексной широкомасштабной автоматизации ошибки в планировании стоят больших денег.
Что же на самом деле можно и нужно считать настоящей бизнес-моделью предприятия? Как добиться того, чтобы создание бизнес-модели принесло практическую пользу всем участникам проекта? Постараемся ответить на эти (и некоторые другие) вопросы. При подготовке статьи мы опирались как на собственный опыт внедрения большой интегрированной системы на российских предприятиях, так и на значительное число известных методик моделирования и внедрения систем (см. список литературы).
Бизнес-модель предприятия — это совокупность графических и текстовых описаний, позволяющих понимать, а в случае использования электронных средств динамического моделирования имитировать процесс управления предприятием.
Обычно бизнес-модель формируется в целях усовершенствования процесса управления, когда руководство понимает, что предприятие должно перейти на новую ступень развития, например, повысить качество производимой продукции или оказываемых услуг, выйти на внешний рынок и т. п.
Наиболее подходящим средством, обеспечивающим качественный рост предприятия, может стать новая интегрированная информационная система управления предприятием. Идеально, когда такая система содержит в себе встроенные средства динамического моделирования деятельности предприятия, позволяющие:
Иными словами, бизнес-модель является отображением предприятия и его информационно-управляющей системы. Без бизнес-модели вы не сможете построить действительно интегрированную и «всеобъемлющую» ИСУ. Именно при создании бизнес-модели формируется «язык общения» консультантов, разработчиков, пользователей и руководителей предприятия, позволяющий выработать единое представление о том, ЧТО и КАК должна делать система управления предприятия («корпоративная система управления»).
Очень важно с самого начала определиться, на кого вы будете ориентироваться при построении модели, то есть, кто будет ее конечным потребителем. В большинстве случаев ответ на этот вопрос один: руководство компании. Все попытки использования точек зрения главного бухгалтера или коммерческого директора превращают модель промышленного предприятия в модель финансового института или торгового дома.
С особой тщательностью следует подходить к формату представления бизнес-модели. Популярная методология SADT (Structured Analysis and Design Technique) или рожденная на ее основе IDEF0 действительно хороши там, где практически отсутствуют описания функций и бизнес-процессов, а также в тех случаях, когда построением модели занимается не единая, слаженная команда, а, например, группа, состоящая из внешних консультантов, экспертов поставщика ИСУ и сотрудников самого предприятия. В таком случае можно гарантировать, что большинство членов «сборной» команды знакомы с общепринятым стандартом IDEF0 (в настоящее время его преподают во многих вузах), следовательно, можно сравнительно быстро приступить к работе над моделью, «поделив» между собой бизнес-функции предприятия. Создаваемые диаграммы будут совместимы друг с другом и смогут впоследствии составить единую модель. Однако характерная для стандарта IDEF0 бедность изобразительных средств делает невозможным, например, описание сквозных бизнес-процессов, охватывающих весь цикл обработки заказа — от размещения до исполнения. Для подобных задач более подходящим инструментом могут служить такие известные системы проектирования, как ARIS («архитектор интегрированных информационных систем») или BAAN DEM («динамический моделировщик предприятий»). В общем, любой способ изображения модели хорош, если он нагляден и понятен руководству предприятия.
Ошибочно полагать, что бизнес-модель — это просто комплект документов, описывающий только бизнес-процессы предприятия. На самом деле в основе бизнес-модели всегда лежат бизнес-цели предприятия, по большому счету полностью определяющие состав всех базовых компонентов бизнес-модели [2] (см. рис. 2):
Рис. 2
Тем не менее, описание бизнес-процессов, как наиболее трудоемкая и чреватая многими ошибками задача, нуждается в конкретной методологической платформе. Поэтому существует наиболее устоявшийся перечень атрибутов, которые модель бизнес-процессов должна описывать на изобразительном уровне, а именно:
Моделирование ни в коем случае не должно стать внутренним процессом отдела ИТ. Так же верно и обратное: если ваше предприятие располагает внушительным бюджетом, позволяющим привлечь большую группу управленческих консультантов, то со стороны заказчика модели в совместную группу моделирования должны входить, помимо полностью выделенных для данного проекта ИТ-специалистов, менеджеры отделов и ключевые пользователи (см. далее пункт «Попытка — не пытка, а путь к истине»). Следует позаботиться о том, чтобы ВСЕ участники проектной группы к моменту начала работ по бизнес-моделированию прошли обучение методологии моделирования, основам проектирования больших систем, а также приобрели минимальные навыки работы с будущей ИСУ — познакомились с архитектурой системы, основами навигации по системе, функциональным назначением подсистем и т.п.
В группе моделирования (внедрения) обязательно должна быть предусмотрена должность администратора бизнес-моделирования (АБМ). АБМ — это координатор усилий всей проектной группы по разработке модели. Ошибочно считать, что эту функцию должен выполнять «по совместительству» менеджер проекта. Его основная (и единственная) обязанность — управление проектом. АБМ же ведет оперативный аудит принимаемых в ходе внедрения решений, контролирует целостность базовой бизнес-модели и процесс ее корректировки, отслеживает оптимальность кодирования справочников и руководит процессом разработки интерфейсов внедряемой ИСУ с другими системами. Естественно, что АБМ подготавливает для менеджера проекта необходимую при принятии решений информацию. Если провести аналогию с государственным управлением, то АБМ — это власть законодательная, а менеджер проекта — власть исполнительная. На ранних стадиях проекта функцию АБМ может и должен (требуйте этого!) исполнять внешний консультант. Но с самого начала вам необходимо приставить к этому человеку специалиста-дублера «из своих», чтобы перенять опыт и полностью принять дела к началу опытной эксплуатации!
При классическом подходе к внедрению новой ИСУ формируются две бизнес-модели: исходная («как есть») и целевая («как будет»). Описание исходной модели требуется для того, чтобы идентифицировать возможные недостатки в существующей системе управления предприятием. Выявление недостатков начинается еще на стадии описания модели «как есть». Дело в том, что в основу любого средства динамического моделирования закладывается та или иная методология структурирования больших массивов знаний об объекте. Любая методология такого рода подразумевает целый комплекс правил разной степени жесткости, несоблюдение которых делает задачу формализации получаемых знаний (то есть само построение модели) практически неосуществимой. Таким образом, невозможность формального целостного описания, например, бизнес-процесса оформления заказа выявляет проблему неоптимальности (излишней разветвленности, дублирования данных, слабого организационного описания и т.п.) самого бизнес-процесса. В местах подобного рассогласования правил и реалий каждый проектировщик вынужден отступать от методологических требований, тем самым визуально акцентируя внимание руководства предприятия на обнаруженных недостатках организации бизнеса.
Главный «подводный камень» моделирования исходной модели — время, которое мы затрачиваем на разработку. Чем динамичнее развивается ваше предприятие, тем меньше времени у вас остается на описание того, «как есть». Если, согласно вашим прикидкам, достоверность модели к моменту ее завершения составит не более 70%, возможно, имеет смысл описать только основные «сквозные» бизнес-процессы, каждый из которых раскрывает последовательность шагов вашего предприятия на пути к извлечению прибыли от того или иного вида деятельности.
Желательно, чтобы консультанты, которых вы привлекаете к проекту, обладали готовой отраслевой моделью. Такая модель-заготовка позволяет значительно сократить время на описание рутинных процессов, которые, каким бы уникальным вы свое предприятие ни считали, составляют львиную долю всех бизнес-процессов в компании. Не исключено, что и поучиться будет чему. Особенно если отраслевая модель представляет собой квинтэссенцию мирового опыта менеджмента в данной отрасли. Но не стоит питать иллюзий — это не «готовое к употреблению» предприятие, в котором как по мановению волшебной палочки сотрудники начинают работать с энтузиазмом, менеджеры перестают делать ошибки, поставщики поставляют то, что заказано, а клиенты вовремя оплачивают счета. Если вспомнить перечень основных компонентов бизнес-модели, то там вы не найдете конкретных данных — справочника изделий, плана счетов, перечня складов и т.п. Ну и, по крайней мере, «готовая модель» обязательно нуждается в тестировании.
Одним из самых важных критериев выбора инструмента моделирования является возможность поддержки нескольких этапов и даже вариантов развития вашего предприятия. Как только будет закончена целевая модель, вы увидите, сколько еще необходимо произвести изменений (от технологических до кадровых) в структуре вашего предприятия, чтобы целевая модель стала реальностью. Наступая впервые на знаменитые грабли «реинжиниринга», некоторые предпочитают рубить сплеча. Гораздо разумнее выстроить на основе моделей «как есть» и «как будет» несколько промежуточных моделей (а точнее, моделей того минимального числа бизнес-процессов, изменение которых предстоит осуществить в первую очередь). Затем выстраивается график введения этих моделей в эксплуатацию. Такой метод последовательных улучшений позволяет ослабить сопротивление на местах, смягчить последствия «шоковой терапии» и, в конце концов, достичь поставленных целей.
Часто методисты в области проектирования и моделирования информационных систем настоятельно рекомендуют производить стоимостный и временной анализ исходной бизнес-модели, то есть строить математическую модель бизнеса. Например, вам предлагают возможность рассчитать среднюю скорость исполнения заказа в целевой модели, с тем, чтобы определить экономическую эффективность внедрения ИСУ. Еще больше независимых консультантов предлагают свои недешевые услуги по проведению вполне академического моделирования с использованием специально разрабатываемых для таких целей программ. Казалось бы, в теории все выглядит красиво. Вам предоставляется возможность получить электронный прототип вашего предприятия, исполнение большинства внутренних бизнес-процесов которого запрограммировано. Такой подход должен давать возможность оценки правильности построения модели путем анализа ее реакции на внешние воздействия. Рискуя навлечь на себя гнев консультантов, зарабатывающих свой хлеб на подобных работах, приходится констатировать, что у тех, кто решился принять такой подход к бизнес-моделированию, постепенно наступает разочарование. Нам не известен ни один факт полноценного завершения математической модели. Поэтому, с нашей точки зрения, наиболее эффективным подходом является незамедлительное начало работ над целевой моделью, как только руководство и ответственные исполнители подтвердили визуальное соответствие исходной модели реальному положению дел. Можно привести несколько весомых аргументов в пользу такого подхода. Во-первых, стоимостной и временной анализ «неживой» модели — это лабораторная работа в области математического моделирования, результаты которой зачастую все равно оказываются далеки от реальных источников потерь предприятия. Во-вторых, такая работа сама по себе требует ощутимого количества временных и стоимостных ресурсов. И, в-третьих, процесс дальнейшего внедрения все равно подразумевает постоянное усовершенствование целевой модели на основе результатов тестирования и опытной эксплуатации.
Как правило, тестирование бизнес-модели проводится на четырех уровнях.
Мы осознанно не приводим здесь перечня существующих инструментальных средств бизнес-моделирования. Исследование рынка таких систем неоднократно проводилось в печати. Важно, чтобы читатель принял во внимание все приведенные правила и практические советы при выборе как средства бизнес-моделирования, так и самой ИСУ. Как мы уже говорили, наиболее оптимальный вариант — когда среда бизнес-моделирования является частью самой ИСУ. В таком случае вы получаете ожидаемый конечный результат бизнес-моделирования — собственно информационную систему управления масштаба предприятия. Дело в том, что чем функционально богаче программная система, выбираемая вами для построения ИСУ, тем больше в ней содержится экранных форм и настроек и тем большее количество пользователей должно в такой системе работать. Если вы привязываете к каждому шагу бизнес-процесса тех или иных исполнителей, вполне логично ожидать, что, в конечном счете, каждый из них получит на своем рабочем месте именно тот набор меню и опций, который ему необходим. При несостыковке систем моделирования и ИСУ такое соответствие достигается «вручную», что влечет за собой излишние затраты времени, сил и денег. Кроме того, происходит постепенное «забывание» бизнес-модели, так как модель перестает отражать реальное и ожидаемое состояние предприятия, что сводит на нет все усилия по ее созданию.
Для поддержания бизнес-модели в актуальном состоянии необходимо создать условия, когда существование документации, формализующей бизнес компании, жизненно необходимо для функционирования самого бизнеса. Например, на одном из предприятий, принявшем решение о широкомасштабном внедрении системы класса ERP, автору данной статьи пришлось настоять на том, чтобы ответственность за разработку и поддержку бизнес-модели была возложена на отдел организационного планирования. Этот отдел до начала проекта занимался тем, что разрабатывал организационную структуру компании, писал положения об отделах и составлял должностные инструкции сотрудников. Специалистам отдела был предложен инструмент, который, во-первых, автоматизировал их труд (теперь и структура, и должностные инструкции в виде диаграмм бизнес-процессов содержались в одной централизованной базе данных), а во-вторых, создал на предприятии ситуацию невозможности структурных изменений без соответствующей модификации бизнес-модели. На предприятиях, сертифицированных по ISO 9000, подобные функции могут быть возложены на соответствующие отделы стандартизации. К сожалению, часто приходится сталкиваться с ситуацией, когда такие отделы просто превращаются в хранилища документации. Как следствие, руководство не получает от этих служб реальной отдачи: инициирования и контроля процессов развития предприятия.
Необходимо помнить, что в силу творческого характера самого процесса моделирования проект очень легко может выйти за собственные рамки, поэтому желательно применять некоторые специфические приемы управления таким проектом, например, технологию контроля итеративных процессов разработки информационной системы — таймбоксинг (Timeboxing — «временной квадрат», см. [1]). Но подробное рассмотрение этого вопроса выходит за рамки данной статьи.
Итак, специалистам, перед которыми стоят задачи выбора прикладного пакета и внедрения ИСУ, стоит помнить следующее.
Дополнительная информация
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||
