Информационные технологии управления / Учебные пособия / ИТУ_Ч2_Зубарев Ю.А., Орлова

Моделирование ради моделирования

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

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

Попытка – не пытка, а путь к истине

Как правило, тестирование бизнес-модели проводится на четырех уровнях.

1.Внутреннее тестирование разработчика. В большинстве случаев рекомендуется объединяться с поставщиком даже на столь ранней стадии развития бизнес-модели. Ему нечего от вас скрывать, тестируя модель «в тылу». Участие проектной группы заказчика необходимо и эффективно на всех стадиях тестирования и обкатки ИСУ.

2.Тестирование проектной группой. Как уже было сказано,

желательно совместить эту стадию с первой, устранив тем самым лишнее ресурсоемкое звено в цепочке приемки модели. Данная стадия выделяется только тогда, когда условия реализации проекта внедрения ИСУ на

221

предприятии выражаются в простом, понятном, но неосуществимом словосочетании «под ключ».

3. Тестирование ключевыми пользователями. Ключевые пользователи на каждой стадии проекта внедрения ИСУ играют разную, но всегда действительно ключевую роль. Так как ключевыми пользователями обычно становятся наиболее опытные и прогрессивные сотрудники отделов (а зачастую и линейные менеджеры), на стадии обследования и построения модели «как есть» они лучше других понимают, как устроено их предприятие сейчас и как можно наиболее оптимально решить те задачи, которые руководство поставило перед ними, формулируя цели внедрения ИСУ. Кстати, правильность реализации этих задач руководству предприятия лучше проверять у самих ключевых пользователей. Что имеется в виду?

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

Группа внешних консультантов при этом не должна вмешиваться

впроцесс тестирования. Приглашенные на данный процесс руководители предприятия, напротив, должны принимать самое активное участие, задавая каверзные вопросы своим подчиненным на предмет того, как в системе будет осуществляться та или иная специфическая операция. При таком подходе ключевые пользователи получают возможность дополнительно «набить руку», а руководители — получить более глубокие знания о системе. (Довольно часто тестирование ИСУ становится очень полезной во многих отношениях деловой игрой. Руководители, получая неизвестные им до сего момента сведения, узнают много нового о своих предприятиях, происходят столкновения интересов, выявляются противники внедрения и т. д. Но это уже совсем другая тема, заслуживающая отдельного обсуждения.)

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

4. Опытная эксплуатация. Это стадия реальной эксплуатации новой системы, при которой учетные операции все еще ведутся в системе «старой». На данной стадии очень важно, вопреки нехватке времени, не вносить диктуемые реальной эксплуатацией требования напрямую в систему, а всетаки изменять сначала бизнес-модель. Во-первых, таким образом вы не дадите умереть бизнес-модели, она останется вашим рабочим инструментом после окончания проекта внедрения и будет использоваться для дальнейшего развития ИСУ. Во-вторых, проводка всех изменений через модель даст

222

возможность не потерять общую картину и не допустить дезинтеграции ИСУ

вцелом, увлекшись частностями.

Основным критерием правильности построения целевой бизнесмодели является сбалансированность целей и средств. Если внедрение модулей интеллектуального планирования производственных ресурсов (например, MRP II) приведет к тому, что раз в сутки на вашем предприятии придется останавливать сборочный конвейер на несколько часов, чтобы получить результаты автоматического распределения производственных заказов, то, очевидно, что-то неправильно в бизнес-модели. При статическом (или «бумажном») рассмотрении модели такое несоответствие разглядеть невозможно.

Не бойтесь многократно повторять процесс тестирования, выявления недостатков, доработки модели и вновь тестирования. В мире нет консультантов или разработчиков, способных построить для вас ИСУ, что называется, с ходу. Лучше с опаской относиться к тем, кто утверждает, что сможет без необходимости дальнейших доработок запустить ИСУ на вашем предприятии в считанные недели.

Чтобы помнили

Мы осознанно не приводим здесь перечня существующих инструментальных средств бизнес-моделирования. Исследование рынка таких систем неоднократно проводилось в печати. Важно, чтобы читатель принял во внимание все приведенные правила и практические советы при выборе как средства бизнес-моделирования, так и самой ИСУ. Как мы уже говорили, наиболее оптимальный вариант – когда среда бизнесмоделирования является частью самой ИСУ. В таком случае вы получаете ожидаемый конечный результат бизнес-моделирования – собственно

информационную систему управления масштаба предприятия. Дело в том,

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

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

223

бизнес-модели была возложена на отдел организационного планирования. Этот отдел до начала проекта занимался тем, что разрабатывал организационную структуру компании, писал положения об отделах и составлял должностные инструкции сотрудников. Специалистам отдела был предложен инструмент, который, во-первых, автоматизировал их труд (теперь и структура, и должностные инструкции в виде диаграмм бизнеспроцессов содержались в одной централизованной базе данных), а во-вторых, создал на предприятии ситуацию невозможности структурных изменений без соответствующей модификации бизнес-модели. На предприятиях, сертифицированных по ISO 9000, подобные функции могут быть возложены на соответствующие отделы стандартизации. К сожалению, часто приходится сталкиваться с ситуацией, когда такие отделы просто превращаются в хранилища документации. Как следствие, руководство не получает от этих служб реальной отдачи: инициирования и контроля процессов развития предприятия.

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

– «временной квадрат»).

Резюме

Итак, специалистам, перед которыми стоят задачи выбора прикладного пакета и внедрения ИСУ, стоит помнить следующее.

Бизнес-моделирование – обязательный этап внедрения ИСУ.

Бизнес-модель:

а) вырабатывает общий язык для проектной группы и руководства; б) сокращает время внедрения ИСУ; в) позволяет вырабатывать пошаговый план развития предприятия.

Методология и само средство моделирования должны обеспечивать понимание модели руководством предприятия.

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

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

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

Инструмент бизнес-моделирования должен поддерживать промежуточные и альтернативные модели.

Лучшим средством проверки правильности модели является ее неоднократное тестирование. Выбирая прикладной пакет для ИСУ,

224

необходимо в первую очередь определиться с инструментарием бизнесмоделирования. В идеале данный инструментарий является встроенной частью (подсистемой) этого программного пакета, а затем бизнес-модель остается частью ИСУ.

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

Одной из задач управления проектом является контроль временных границ творческого процесса проектирования.

2.4.5. Наиболее эффективные методы внедрения систем управления

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

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

Ссамого начала убедитесь, что проект правильно организован.

1.Добейтесь веры в успех и преданности делу со стороны тех, кто играет ключевую роль в реализации проекта. Попросите этих людей добиться такой же веры от своих подчиненных.

2.Определите, кто будет штатным руководителем проекта по внедрению системы. Этот человек должен обладать необходимыми навыками для выполнения такой работы, желательно, чтобы он имел опыт внедрения систем.

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

225

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

5.Разработайте подробный план работы, разбейте его на этапы, определите сроки выполнения задач и придерживайтесь их.

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

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

2.Опишите методы ведения хозяйственной деятельности и действия, которые должны быть выполнены в результате их применения.

3.При необходимости измените эти методы так, чтобы они обеспечивали более эффективную работу и интеграцию новой системы.

4.Опишите организационную структуру и подумайте о том, в максимальной ли степени она отвечает целям вашего предприятия.

5.Забудьте такие популярные клише, как ―реинжиниринг‖ и ―сокращения‖. Вам не обязательно начинать с нуля, осуществляемые изменения не обязательно должны носить радикальный характер, а число ваших сотрудников не обязательно должно быть сокращено.

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

Обеспечьте создание необходимой технической инфраструктуры.

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

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

Убедитесь, что система отвечает основным потребностям всех пользователей.

1.Документально зафиксируйте потребности бизнеса с той степенью подробности, которой будет достаточно для сравнения одной системы с другой.

2.Всегда определяйте приоритеты.

3.Пользуйтесь полученными документами, чтобы убедиться, что реализованные функции отвечают вашим потребностям.

Управляйте изменениями, подстраиваясь под своих сотрудников.

1.Проводите изменения постепенно, не забывая о том, что за один раз сотрудники могут освоить лишь определенное количество информации.

2.С самого начала задействуйте всех, кто играет основную роль в осуществлении проекта. Хороший способ добиться этого – попросить их

226

высказывать свое мнение в процессе подробного определения потребностей бизнеса.

3.Регулярно общайтесь с такими сотрудниками, давая им возможность быть услышанными.

4.Разработайте план обучения таким образом, чтобы люди не просто научились осуществлять ввод данных в систему, но поняли, как изменится их работа. Помогите пользователям системы увидеть ―полную картину‖.

Наиболее неэффективные методы внедрения

Иногда поджимающие сроки, бюджетные ограничения и/или попросту недостаток опыта и знаний приводят к спешке, способной обречь проект на провал. Ошибок, возникающих при внедрении системы, особенно трудно избежать в России, где ограниченность в средствах зачастую носит более острый характер, чем на Западе.

Ваш проект по внедрению системы управления предприятием скорее всего потерпит неудачу, если вы:

1.при выборе системы будете основываться на ее присутствии на рынке, а не на том, насколько она подходит для удовлетворения потребностей бизнеса компании;

2.приступите к внедрению, имея слабого руководителя проекта (или вовсе без него) или план проекта, который не был тщательно продуман;

3.не пересмотрите методы ведения хозяйственной деятельности компании до выбора системы;

4.не будете регулярно общаться с сотрудниками, стремясь привлечь их к участию во внедрении системы и дать им возможность убедиться в том, что их потребности учтены;

5.не будете следить за ходом выполнения проекта, сверяясь с намеченными основными этапами и сроками выполнения задач;

6.установите нереальные сроки и составите заниженный бюджет;

7.не приведете в соответствие с новыми требованиями уровень подготовки сотрудников отдела информационных систем;

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

2.5.Корпоративные информационные системы

2.5.1. Краткий обзор систем управления бизнесом

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

227

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

Западные аналитики различают два вида корпоративных информационных систем: Business Management Systems (BMS) – системы управления бизнесом и Enterprise Recourse Planning (ERP) – системы планирования ресурсов предприятия.

В свою очередь, BMS – системы разбиваются на три группы. В первую из них входят простые системы, предназначенные для автоматизации малых предприятий. Системы этой группы рассчитаны на выполнение весьма ограниченного числа стандартных бизнес - процессов и представляют собой «коробочный продукт». Как правило, они работают на одном рабочем месте или в небольших сетях из 4 – 8 компьютеров. За рубежом такие системы называют «Low End PC». Отечественным примером системы такого уровня является «1С Бухгалтерия».

Ко второй группе, называемой «Middle PC», относят системы, отличающейся большей глубиной и широтой охвата функций. Они нуждаются в настройке, которую в большинстве случаев осуществляют специалисты фирмы-разработчика. В такой системе могут быть описаны десятки бизнес - процессов. В основном данные системы автоматизируют бухгалтерский и/или складской учет, как например «1C Предприятие».

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

―Галактика‖, ―NS2000‖; среди западных – «Concorde XAL».

Высший уровень иерархии занимают системы, которые обеспечивают планирование и управление всеми ресурсами предприятия и строятся на основании MRP/ERP модели, то есть ERP-системы. В них содержится описание тысяч бизнес - процессов. Такие системы могут иметь до 100 тысяч настраиваемых параметров, позволяющих реализовать огромное многообразие требований различных предприятий. ERP-системы удовлетворяют большинству запросов как средних, так и очень крупных предприятий. Они могут работать на различных платформах (Windows NT,

228

UNIX, Solaris, AIX и т.д.) и с различными мощными профессиональными СУБД.

На мировом рынке представлено около трех десятков полноценных ERP-систем. В России систем подобного уровня пока еще не создано. Затраты на создание ERP-системы оцениваются экспертами в несколько тысяч человеко-лет с вытекающими отсюда финансовыми и организационными затратами. Кроме того, очень важным для столь сложных информационных систем является процесс апробации на множестве предприятий. Только после нескольких десятков успешных внедрений ERPсистема может претендовать на рыночный успех, поскольку только тогда она аккумулирует в себе достаточный опыт предметных специалистов и необходимые управленческие технологии. Чтобы вернуть инвестиции и получить прибыль, компания-разработчик ERP-системы должна обеспечить ей высокий уровень продаж. Но рынок России и стран СНГ, даже по самым оптимистическим оценкам, не способен пока обеспечить спрос в миллиарды долларов за системы подобного класса. Это значит, что система должна хорошо продаваться на западных рынках, прежде всего в США. Все без исключения лидеры рынка ERP-систем смогли занять свои позиции только после успеха на самом богатом американском рынке. Так как у нас только начинается развитие экономики предприятий на базе MRP/ERP – моделей, то пройдет немало времени, прежде чем в России появятся специалисты, которые научатся не только разбираться в современных методах управления предприятиями, но и создавать программные продукты, реализующие эти методы. Однако ничто не препятствует уже сейчас использовать мировой опыт применения информационных технологий для управления предприятиями, поскольку многие из ERPсистем представлены в России, переведены на русский язык и адаптированы к требованиям российского законодательства.

Сейчас практически все современные западные производственные системы и основные системы управления производством базируются на концепции ERP и отвечают еѐ рекомендациям, которые вырабатываются американской общественной организацией APICS, объединяющей производителей, консультантов в области управления производством, разработчиков программного обеспечения. К сожалению, большинство из российских систем управления производством не удовлетворяет пока даже требованиям MRP, не говоря уже обо всех остальных более развитых концепциях (см. Таблицу 1).

Последний по времени стандарт CSRP (Customer Synchronized Resource Planning) охватывает кроме управления непосредственно предприятием также и взаимодействие с клиентами: оформление технического задания, наряд – заказа, поддержку заказчика на местах и пр. Таким образом, если MRP, MRP-II, ERP ориентировались на внутреннюю организацию предприятия, то CSRP включил в себя полный цикл от проектирования будущего изделия, с учетом требований заказчика, до гарантийного и сервисного обслуживания после продажи. Основная суть концепции CSRP в

229

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

На мировом рынке сейчас предлагается свыше 500 систем класса BMS (в том числе и системы класса MRP II-ERP). Рынок бурно растет - на 35% - 40% каждый год. В настоящее время в России присутствуют около десятка западных систем и три-четыре отечественные информационные системы, которые можно отнести к корпоративным. Для того чтобы понять, кто есть кто на рынке информационных систем для предприятий России, ниже предлагается классификация информационных систем (см. Таблицу 2.5.1).

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

продуктам SAP R/3, Baan и Oracle Application. Действительно, помимо высоких цен, программные продукты этих корпораций сложны для внедрения в российских условиях: во-первых, в России элементарно не хватает специалистов по внедрению достаточной квалификации, а во-вторых, эти системы требуют от заказчика серьезной реорганизации управления.

При формировании рисунка 2.5.1 использованы данные аналитического отчета «Выбор тиражируемой интегрированной системы управления предприятием», раз в полгода выпускаемого независимой исследовательской компанией RC Group и корпорацией "МетаСинтез" (Они не претендуют на абсолютную полноту, а отражают состояние исследований на октябрь 2000 года. Системы, отмеченные как (2*), подробно представлены в аналитическом отчете и за их правильную квалификацию эксперты RC Group и «МетаСинтез» несут ответственность. Остальные системы квалифицированы так, как это представляют их разработчики.

Приведенные в таблице системы отличаются от всех прочих присутствующих на российском рынке программных продуктов для автоматизации финансово-хозяйственной деятельности (FTP), во-первых, наиболее развитой функциональностью, а также тем, что в них или уже присутствует модуль планирования производства и оперативного управления им (MRP), или разработчики системы обещают появление таких возможностей в ближайшие два года (т.е. уже идет работа над реализацией этих задач). Достоинством и одновременно недостатком систем ERP уровня из первой тройки (R/3, BAAN, Oracle Application) является их универсальность. Иными словами, у «гигантов» есть референтные модели для любого типа производственного процесса, и количество автоматизированных рабочих мест определяется исключительно финансовыми возможностями заказчика. Но и возможности эти должны быть серьезными. Проект с использованием такой системы не может обойтись дешевле 500 тысяч долларов, а чаще всего стоит несколько миллионов.

230