Лекция 5. Разработка и внедрение КИС: основные аспекты разработки бизнес-моделей
МОТИВЫ РАЗРАБОТКИ БИЗНЕС-МОДЕЛИ
Несмотря на вполне к настоящему времени сложившиеся и хорошо себя зарекомендовавшие парадигмы технологии программирования, разработка и эксплуатация некоторых типов программных продуктов имеет специфические особенности. Главной особенностью разработки КИС является их жёсткая привязка к той или иной бизнес-модели конкретного предприятия, и именно корректность и «удачность» такой модели и определяет в значительной степени успешность разработки, внедрения и последующей эксплуатации корпоративных информационных систем.
В данном ключе проект создания и внедрения КИС состоит из двух этапов:
-
разработка прототипа будущей системы (называемого также «бизнес-моделью», «проектным решением» и т. п.);
-
развертывание системы или ее части.
Таким образом, специфические для КИС особенности будут иметь следующие фазы разработки ПО: планирование и тестирование.
При выработке стратегии управления проектом разработки КИС целесообразнее всего не рассматривать данный проект как единый контракт — от обследования до ввода в промышленную эксплуатацию интегрированной системы по всем участкам предприятия. Оптимальным решением будет заключение на начальном этапе контракта с поставщиком или с консалтинговой фирмой исключительно на стадию бизнес-моделирования. Получаемая при этом в качестве результата бизнес-модель это уже некоторый результат, с помощью которого можно максимально конкретизировать цели внедрения КИС и определиться со следующими параметрами проекта:
-
перечень участков внедрения и последовательность их автоматизации;
-
фактическая потребность в объемах закупаемого программного и аппаратного обеспечения;
-
реальные оценки сроков развертывания и запуска КИС;
-
уточненный список членов команды внедрения и ключевых пользователей;
-
степень соответствия выбранного прикладного ПО специфике бизнеса компании и многое другое.
Создание бизнес-модели это достаточно длительный процесс (занимает обычно от четырех до девяти месяцев), однако его значимость определяется тем, что при комплексной широкомасштабной автоматизации ошибки, допущенные при планировании, могут стоить очень больших затрат. Имея в виду, что разрабатываемая при этом модель будет являться базисом для всех дальнейших работ по КИС в контексте технологии программирования, она должна представлять собой формализованную совокупность графических и текстовых описаний, позволяющих понимать, анализировать и имитировать процесс управления предприятием.
ФОРМЫ ПРЕДСТАВЛЕНИЯ БИЗНЕС-МОДЕЛЕЙ
К формату представления бизнес-моделей следует подходить с особой тщательностью – хорош лишь тот способ изображения бизнес-моделей, который нагляден и понятен руководству предприятия. В настоящее время существует довольно много стандартных методологий (IDEF, ABC и т.д.), полезных в тех случаях, когда построением модели занимается не единая, слаженная команда, а, например, группа, состоящая из внешних консультантов, экспертов поставщика КИС и сотрудников самого предприятия. Использование стандартных подходов позволяет в этом случае сравнительно быстро приступить к работе над моделью, «поделив» между собой бизнес-функции предприятия. Создаваемые диаграммы будут совместимы друг с другом и смогут впоследствии составить единую модель. Некоторым недостатком стандартных подходов является, однако, характерная бедность изобразительных средств. На примере показано, как графическими средствами стандарта IDEF3 документируется производственный процесс окраски детали. Данный процесс состоит непосредственно из самой окраски, производимой на специальном оборудовании и этапа контроля ее качества, который определяет, нужно ли деталь окрасить заново (в случае несоответствия стандартам и выявления брака) или отправить ее в дальнейшую обработку.
Бизнес-модель является не просто набором документов, иллюстрирующим процессы предприятия. На самом деле в основе бизнес-модели всегда лежат бизнес-цели предприятия, полностью определяющие состав всех базовых компонентов бизнес-модели:
-
бизнес-функции, описывающие, ЧТО делает бизнес;
-
бизнес-процессы, описывающие, КАК предприятие выполняет свои бизнес-функции;
-
организационная структура, определяющая, ГДЕ исполняются бизнес-функции и бизнес-процессы;
-
фазы, определяющие, КОГДА (в какой последовательности) должны быть внедрены те или иные бизнес-функции;
-
роли, определяющие, КТО исполняет бизнес-процессы;
-
правила, определяющие связь между ЧТО, КАК, ГДЕ, КОГДА и КТО.
Описание бизнес-процессов это довольно трудоемкая и нуждающаяся в конкретной методологической платформе задача. Поэтому существует наиболее устоявшийся перечень атрибутов, которые модель бизнес-процессов должна описывать на изобразительном уровне, а именно:
-
воздействия, инициирующие каждый шаг бизнес-процесса;
-
исполнители каждого шага (это могут быть как люди, так и программы и механизмы);
-
воздействия, регламентирующие данный шаг (законодательные акты, рыночные условия и т. п.);
-
результат, получаемый на выходе конкретного шага бизнес-процесса.
ОСНОВНЫЕ АСПЕКТЫ ПРОЦЕССА МОДЕЛИРОВАНИЯ
Среди основных моментов, характеризующих процесс моделирования, можно выделить следующие:
-
проблема достоверности разрабатываемой бизнес-модели в условиях изменчивости;
-
проблема использования типовых отраслевых моделей;
-
проблема реинжениринга
Проблема достоверности. При классическом подходе к внедрению новой КИС формируются две бизнес-модели: исходная («как есть») и целевая («как будет»). Описание исходной модели требуется для того, чтобы идентифицировать возможные недостатки в существующей системе управления предприятием. Главный «подводный камень» моделирования исходной модели — время, затрачивается на разработку. Чем динамичнее развивается автоматизируемое предприятие, тем меньше времени имеется на описание того, «как есть». Если, согласно предварительным оценкам, достоверность модели к моменту ее завершения составит не более 70%, возможно, имеет смысл описать только основные «сквозные» бизнес-процессы, каждый из которых раскрывает последовательность шагов предприятия на пути к извлечению прибыли от того или иного вида деятельности.
Проблема использования типовых моделей.
Очень желательно, чтобы консультанты, которые привлекаются к проекту, обладали готовой отраслевой моделью. Такая модель-заготовка позволяет значительно сократить время на описание рутинных процессов, которые, каким бы уникальным ни было автоматизируемое предприятие, всегда составляют львиную долю всех бизнес-процессов в компании. Приведём в качестве примера бизнес-процесс закупки – типичный в подавляющем большинстве случаев:
-
Подготовка и оформление заявки на материал
-
Определение потребности в материале
-
Подготовка заявки на материал
-
Оформление заявки на материал
-
Согласование заявки на материал
-
-
Выбор поставщиков
-
Подготовка списка возможных поставщиков
-
Отправка запроса, в соответствии с заявкой на материал
-
Организация или возобновление переписки с возможными поставщиками
-
Подготовка и оформление запроса в соответствии с заявкой на материал
-
Отправка запроса на материал
-
Регистрация отправки запроса возможным поставщикам
-
-
Выбор поставщиков
-
Получение коммерческих предложений от возможных поставщиков
-
Согласование полученных предложений
-
Регистрация получения предложений
-
Выбор наиболее подходящих поставщиков
-
-
-
Обработка заказов
-
Оформление и отправка заказа
-
Подготовка заказа
-
Проверка на наличие долгосрочных договоров с Поставщиком
-
Оформление или продление договора с Поставщиком
-
Оформление заказа
-
Отправка заказа выбранному Поставщику
-
Регистрация отправки заказа
-
-
Выполнение обязательств по оплате заказа
-
Получение инвойса в соответствии с заказом
-
Cогласование полученного инвойса
-
Выполнение обязательств по оплате заказа
-
Отправление уведомления о выполнении обязательств по оплате
-
Получение уведомления о сроках готовности к отгрузке
-
-
-
Контроль выполнения условий договора
-
Отслеживание местонахождения груза в процессе доставки
-
Регистрация отступлений от контрольных дат по условиям поставки
-
-
Поступление материала
-
Организация приёма груза в установленном месте
-
Сопоставление характеристик и качества полученного материала с заявленными Поставщиком
-
Выставление претензий по факту отступления от условий договора
-
-
Оприходование материала
-
Контроль счетов
Не исключено, что воздействие этой типовой модели будет весьма полезным – такие модели, как правило, представляет собой квинтэссенцию мирового опыта менеджмента в данной отрасли. Не стоит при этом, правда, и питать иллюзий: типовая модель – это не «готовое к употреблению» предприятие; кроме того, любая типовая модель нуждается в тестировании.
Проблема реинжениринга. Одним из самых важных критериев выбора инструмента моделирования является возможность поддержки нескольких этапов и даже вариантов развития вашего предприятия. После разработки моделей «как есть» и «как будет», станет понятно, сколько необходимо произвести технологических и кадровых изменений в структуре предприятия, чтобы целевая модель стала реальностью. Разумнее всего при этом выстроить на основе моделей «как есть» и «как будет» несколько промежуточных моделей. Затем выстраивается график введения этих моделей в эксплуатацию. Такой метод последовательных улучшений позволяет ослабить сопротивление на местах, смягчить последствия «шоковой терапии» и в конце концов достичь поставленных целей.
ПРОЦЕСС ТЕСТИРОВАНИЯ БИЗНЕС-МОДЕЛИ
Под тестированием бизнес-модели понимается имитация её функционирования в режиме опытной эксплуатации. Как правило, тестирование бизнес-модели проводится на четырех уровнях.
Внутреннее тестирование разработчика. На этом уровне разработчик тестирует базовую функциональность и соответствие основным требованиям.
Тестирование проектной группой. На этом уровне происходит проверка самых общих пользовательских функций системы с точки зрения её работы «под ключ».
Тестирование ключевыми пользователями. Специально для целей тестирования выделяется рабочее помещение, где установлено несколько компьютеров, подключенных к КИС, сконфигурированной в соответствии с текущей версией бизнес-модели. Группа ключевых пользователей самостоятельно имитирует работу своего предприятия по специально разработанному сценарию теста. Организационная структура моделируемого предприятия должна быть разумно упрощена, иначе каждому ключевому пользователю придется слишком часто подключаться к системе от имени сотен рядовых пользователей.
Группа внешних консультантов при этом не должна вмешиваться в процесс тестирования. Приглашенные на данный процесс руководители предприятия, напротив, должны принимать самое активное участие, задавая вопросы своим подчиненным на предмет того, как в системе будет осуществляться та или иная специфическая операция. При таком подходе ключевые пользователи получают возможность дополнительно «набить руку», а руководители — получить более полное представление о системе. Группа внешних консультантов, в зависимости от успешности сдачи ключевыми пользователями бизнес-модели своему руководству, получает оценку собственной работы.
Опытная эксплуатация. Это стадия реальной эксплуатации новой системы, при которой учетные операции все еще ведутся в системе «старой». На данной стадии очень важно не вносить диктуемые реальной эксплуатацией требования напрямую в систему, а все-таки изменять сначала бизнес-модель. В этом случае проводка всех изменений через модель даст возможность не потерять общую картину и не допустить дезинтеграции КИС в целом, увлекшись частностями.
Основным критерием правильности построения целевой бизнес-модели является сбалансированность целей и средств. Если внедрение модулей интеллектуального планирования производственных ресурсов (например, MRP II) приведет к тому, что раз в сутки на вашем предприятии придется останавливать сборочный конвейер на несколько часов, чтобы получить результаты автоматического распределения производственных заказов, то, очевидно, что-то неправильно в бизнес-модели. Подобные несоответствия бизнес-модели можно увидеть только при эксплуатации системы. При статическом (или «бумажном») рассмотрении модели такое несоответствие разглядеть чаще всего невозможно.