Заметки о методологии, стратегии и тактике построения корпоративных информационных систем
Этой статьей хотелось бы продолжить дискуссию по проблемам построения корпоративных информационных систем (КИС) управления предприятием, начатую еженедельником PC Week/RE в публикациях “КИС’кин дом”, и к участию в ней пригласить тех, кому по долгу службы приходится разрабатывать подобные системы. В первую очередь - руководителей конкретных проектов построения КИС и руководителей предприятий, которые решились на создание или модернизацию уже существующих информационных систем такого класса. (Заметим, что автор статьи не является сотрудником PC Week/RE и сам относится к категории экспериментаторов в области КИС. - Прим. ред.)
Вместо определения
КИС представляют собой довольно сложный конгломерат программно-аппаратных средств и процедур для согласованного решения разнородных управленческих задач, стоящих перед руководством предприятия. Можно считать, что КИС - это информационная система, функционирующая в компьютерной сети масштаба предприятия (enterprise-wide network), отличительными признаками которой являются территориальная распределенность узлов (несколько производственных площадок), гетерогенность вычислительной среды (различные протоколы, операционные платформы, используемые СУБД), разнородность приложений пользователей (их целевая направленность) и немалое число пользователей различной квалификации.
Основное предназначение КИС состоит в информационном и математическом моделировании динамичного виртуального предприятия с целью отражения текущего состояния реального предприятия и прогнозирования его развития. При построении таких систем можно опираться на различные методологические подходы и тактические приемы, что обусловливает их многообразие на практике. Чтобы конкретизировать обсуждение концептуальных и принципиальных аспектов разработки КИС, давайте остановимся на административных системах управления (УИС - управляющие информационные системы или MIS - Management Information System). Подобные системы могут и не попадать в класс КИС, но чаще всего они к ним принадлежат.
Каждая ИС имеет свое “лицо”, т.е. обладает неповторимой индивидуальностью, хотя все они предназначены для решения схожих задач. Эта индивидуальность определяется теми концептуальными решениями, которые принимают руководители проектов при создании системы. Скажем прямо, большинство руководителей таких проектов вынуждены работать по принципу “один пишем, два в уме” (размышляя на уровне: дадут сделать, - хочу сделать) и не часто обсуждают с кем-либо те заветные идеи, которые составляют основу создаваемой ими программной системы. За свой почти двадцатилетний опыт работы в области создания ИС с базами данных (порядка 30 систем различной сложности) мне приходилось обсуждать такие идеи не более трех раз (поскольку предпочтительнее не распространяться об этом). Однако, немного абстрагируясь от конкретного проекта, было бы очень интересно узнать точку зрения своих коллег на методологические принципы и подходы к построению КИС.
Общий контур системы, или “Чего от нас хотят”
Заказчиками УИС являются руководители предприятий, будем далее называть их лицами, принимающими решения (ЛПР). Именно они определяют внешний облик системы и ее живучесть (продолжительность жизненного цикла). Фактически система должна отвечать манере управления ЛПР, которая обычно меняется с течением времени.
В зависимости от широты взглядов ЛПР на концепции и методы управления обычно требуется быстро создать на основе распределенной вычислительной среды того или иного уровня сложности информационную модель деятельности предприятия (так называемое виртуальное предприятие) и воплотить ее в реально действующую автоматизированную систему управления предприятием, которая включает:
- электронный документооборот (или, согласно российским государственным стандартам, электронное сопровождение бумажного документооборота);
- оперативную систему обеспечения управленческих решений за счет информатизации структурных подразделений предприятия;
- систему принятия и поддержки решений (но этот компонент системы почему-то стараются так не называть) для моделирования и прогнозирования деятельности предприятия.
Это означает, что информацию, циркулирующую вне и внутри предприятия, следует сделать непосредственным участником производственного процесса и процесса управления. Подобный взгляд на глобальную цель УИС подразумевает изменение стереотипов подготовки и принятия управленческих решений.
Ремарка 1. Первая ошибка: ЛПР “отдает инициативу бюрократиЧеской лестнице”
Такая формулировка цели УИС описывает исключительно желательную, но совершенно неприемлемую в рамках предоставляемого бюджета, времени и ресурсов ситуацию. Руководители проектов начинают бороться за ограничение предметной области и приведение задачи под реальные программно-аппаратные возможности. ЛПР прекрасно понимают, что создать такую систему весьма сложно и поэтому совершают первую ошибку: “Поскольку сделать то, что мне требуется, невозможно, то пусть сделают, что смогут”.
В такой ситуации система начинает “расползаться” по структурным подразделениям, что приводит к доминированию требований руководителей второго и даже третьего эшелона управления. Изменение доминанты приводит к перекосу ранжирования основных функций системы и, как следствие, увеличению ее фрагментарности и несбалансированности в предоставлении электронных и бумажных документов для принятия решений. Под фрагментарностью системы понимается наличие замкнутых подсистем, ориентированных в первую очередь на удовлетворение информационных потребностей конкретного структурного подразделения. Наличие подобных “опухолей” делает систему непрозрачной при использовании ее для принятия управленческих решений.
В том случае, если заказчиком является сторонняя организация, предметную область можно сразу ограничить, ориентируясь на бюджет и возможности аппаратной платформы. В условиях российского рынка стоимость системы приходится занижать, чтобы иметь возможность работать с этим заказчиком. Ограничения по бюджету делают большинство разработок КИС изначально убыточными для руководителей проекта из-за необходимости идти на компромиссы.
Что следует из определения цели
В любом случае приходится разделять концепцию эволюционного развития системы и, следовательно, ориентироваться на методологию проектирования Midlle-of-Design или Bоttоm-of-Design.
Первая требует наличия “ядра системы”, т. е. функционально полного прототипа, который можно постепенно развивать и расширять по мере эволюции системы. Эта методология удобна при построении системы в условиях плохо определенной постановки задачи. К ней редко прибегают, но случаи ее успешного применения (RAD-технология, CASE высокого уровня с DataImart) имеют место.
Методология проектирования ИС Bottom-of-Design известна давно; это практически единственный подход к интеграции совокупности информационных подсистем в единую КИС управления предприятием. Ее назначение состоит в фиксации уже существующей ситуации в электронных потоках информации на предприятии и, фактически, в создании прототипа КИС для дальнейшего развития.
Применение методологии Top-of-Design в конечном счете сводится к созданию прототипа системы, но во многих случаях экономически оправданно, особенно если модернизация существующей системы идеологически невыгодна или требует высоких трудозатрат.
Но какую бы методологическую точку зрения ни принял руководитель проекта, чтобы обеспечить эволюционное развитие системы, он должен зафиксировать в информационной модели виртуального предприятия следующее:
- текущее состояние данных и информационных потоков (построить информационную модель “что есть”);
- инструментарий для моделирования и реинжиниринга КИС на всех уровнях представления данных;
- конечный результат (решить очень важный вопрос, на кого это все должно работать, и построить информационную модель “что может быть”).
Результатом работы над информационной моделью виртуального предприятия должно быть создание понятийного словаря данных предметной области и базы метаданных системы, которые составят основу репозитария данных для построения системы. Жизнь предприятия состоит из совокупности событий производственной деятельности, которые переводят его из одного состояния в другое. События могут быть внешними и внутренними, но в любом случае они влекут за собой выполнение управляющих воздействий, типовых и нетиповых операций и т. д. Поэтому не имеет особого значения, каким способом будет построена основа репозитория системы. Если бы на рынке информационных услуг появились промышленные оболочки для создания КИС, время разработки таких систем можно было бы значительно сократить. Выбор операционной платформы зависит от выбора СУБД. Важно определить, может ли СУБД поддерживать реляционную (для транзакционной составляющей системы) и постреляционную (для ее информационной составляющей) модели.
Из общей постановки задачи ясно, что помимо превращения бумажных документов в их электронные эквиваленты при соблюдении стандартов российского делопроизводства в желаемой системе должны присутствовать как оперативная (транзакционная), так и информационная (аналитическая) составляющие. А это два фундаментально различных типа систем. Сегодня это означает параллельное и согласованное использование реляционной и постреляционной модели в рамках одной системы. Архитектура системы усложняется, стоимость разработки резко возрастает.
Помимо этого автоматизация (с помощью отечественных, зарубежных или разрабатываемых в самой организации) систем класса Docflow или Workflow не всегда приводит к ожидаемому эффекту упорядочения документооборота. Для решения этой триединой задачи необходимо исследование бизнес-процессов предприятия.
Ремарка 2. Вторая ошибка: “попытка бежать впереди головы своей лошади”
Несмотря на осознание ЛПР необходимости исследования бизнес-процессов своего предприятия и их скрупулезного анализа (определить, что имеем, что хотим и что для этого нужно), они не хотят тратить время и средства на такие исследования. Поэтому руководителям проектов приходится начинать сразу с создания системы, откладывая все прочее на потом. Это означает работу на информационном поле данных с белыми пятнами, которая на практике выливается в создание узкоспециализированных приложений (и реализацию принципа модульности со всеми особенностями связей по данным и управлению). В результате возрастает сложность управления данными в системе и снижается адаптируемость системы к изменениям структуры предметной области.
Генеральный бизнес-план предприятия - основа развития КИС
Степень сложности разрабатываемой системы определяется в зависимости от того, как ЛПР понимает уровни управления предприятием, протокольные и непротокольные взаимосвязи между ними. Именно требования ЛПР составляют предоснову спецификаций системы, определяющих ее основные функции. С учетом этих спецификаций руководитель проекта принимает программно-аппаратные решения. Каково должно быть основное требование к формированию таких спецификаций?
Контролирующим рычагом всех программных решений является бюджет. Принимаемые решения должны соответствовать финансовым возможностям и функциональному назначению системы. Не имеет смысла строить систему на основе решений, предлагаемых одним из лидеров в области информационных технологий - фирмой Oracle - для автоматизации деятельности трех аптечных киосков, работающих по принципу консигнации товара. Расходы на создание такой системы намного превысят бюджет самого предприятия. Но следует помнить, что все УИС решают методологически сходные задачи управления.
Схожесть подобных систем определяется деятельностью предприятия на рынке, т. е. его генеральным бизнес-планом. Для руководителя проекта это и есть основной критерий оценки функциональности КИС, потому что он не зависит ни от конъюнктуры рынка информационных технологий, ни от сиюминутной трактовки назначения системы ЛПР.
В начале восьмидесятых годов на Западе осознали тот факт, что планирование и развитие информационных систем организации должно быть согласовано между собой и обязано следовать генеральному бизнес-плану предприятия. Замечательно, что и в России ЛПР уже осознали необходимость такого подхода в условиях рынка (при этом они могут учесть опыт и ошибки зарубежных коллег). Это можно признать одним из самых грандиозных успехов компьютерной прессы.
Однако соединения генерального бизнес-плана предприятия с планом разработки КИС недостаточно для того, чтобы понять, какова должна быть информационная система, в какой момент и какой уровень ее сложности нужно реализовать. Для этого необходимо осознание другого факта: система должна соответствовать уровням управления предприятием.
Ремарка 3. Третья ошибка: “потеря в системе уровней управления предприятием”
Желание сразу увидеть на экране компьютера всю доступную информацию, циркулирующую на предприятии, порождает иллюзию принятия компетентных управленческих решений. Почему? Человек по своей природе не может одновременно анализировать более пяти-семи факторов, компьютер же анализирует сразу множество факторов. Вот только вклад этих факторов в конечный результат совершенно различен. Обилие информации не способствует формированию оптимального решения из-за ее избыточности. Хотя хорошо известно, что решения принимаются и в условиях неопределенности, и в условиях недостатка информации.
Чтобы управлять сложными системами, природа придумала иерархию, которая находит свое воплощение и в организации управления предприятием. На любом предприятии существует своя иерархия управления, и каждому узлу этой иерархии отвечает свой уровень управления. Информация для каждого уровня не должна быть избыточной. Нужно, чтобы УИС соответствовала уровням управления предприятием и в то же время обеспечивала прозрачность доступа к информации любого уровня системы. Требование такого соответствия определяет требования к функциональной структуре УИС.
Очень часто в спецификациях системы происходит слияние различных уровней управления предприятием. В этом случае разрабатываемая система изначально не соответствует принятой структуре управления и, как следствие, плохо адаптируется к изменению генерального бизнес-плана предприятия.
Например, в определенных спецификациях уровень сетевого транспорта ставится во главу разрабатываемой системы, то есть совсем не туда, где ему предписано находиться. Одно дело “гонять документы по сети” с помощью Lotus Notes и совсем другое - принимать обоснованные управленческие решения. Систему обеспечения управленческих решений нельзя также заменить электронной почтой - в рамках предприятия иногда эффективнее использовать телефон. Предназначение упомянутых программных средств - формирование электронных документов и передача их электронным способом. И не более того. 4
(Окончание следует)
Владимир Туманов
К Владимиру Туманову можно обратиться по адресу: tve@icp.ac.ru.
