ГЛАВА 12

К оглавлению 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
34 35 36

ПОСТРОЕНИЕ МОДЕЛЕЙ

12.1. Построение и анализ моделей деятельности предприятия

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

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

модели “как должно быть”, интегрирующей перспективные предложения руководства и сотрудников предприятия, экспертов и системных аналитиков по совершенствованию деятельности предприятия.

При этом переход от модели “как есть” к модели ”как должно быть” обычно осуществляется следующими двумя способами:

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

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

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

В рамках создания моделей деятельности должен быть осуществлен:

анализ функциональной деятельности структурных подразделений предприятия;

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

анализ внутреннего документооборота структурных подразделений;

анализ информационных потоков и информационного взаимодействия структурных подразделений;

анализ применяемых в настоящее время средств автоматизации как в структурных подразделениях, так и на предприятии в целом.

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

количество потребителей продукции предприятия;

стоимость издержек производства продукции;

длительность типовых операций производства продукции;

дублирование и противоречивость функций, информационных потоков и документооборота;

стоимость и длительность выполнения отдельных шагов технологии или отдельных технологических цепочек шагов;

дублирование и противоречивость выполнения отдельных шагов технологии или отдельных технологических цепочек шагов;

степень загруженности структурных подразделений и должностных лиц;

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

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

Результатом проведения анализа и оценки являются предложения по совершенствованию деятельности предприятия, а именно:

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

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

по созданию перспективной оргштатной структуры предприятия, осуществляющей реализацию рациональных технологий работы;

по изменению информационных потоков и документооборота, обеспечивающих реализацию рациональных технологий работы;

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

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

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

распределение сотрудников структурных подразделений и материальных средств по решаемым задачам;

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

В связи с вышесказанным каждая из моделей деятельности должна включать:

полную функциональную модельс глубиной проработки до уровня конкретного действия должностного лица структурного подразделения предприятия;

информационную модель, интегрированную с функциональной моделью;

динамические, стоимостные, событийные и т.п. модели для осуществления соответствующих оценок.

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

1) Разработка структурной функциональной модели деятельности предприятия:

определение информационных потоков между основными процессами деятельности, связей между процессами и внешними объектами;

оценка объемов и интенсивности информационных потоков;

разработка иерархии диаграмм, образующих структурную функциональную модель деятельности предприятия;

анализ и оптимизация структурной функциональной модели.

2) Разработка информационной модели предприятия:

определение сущностей модели и их атрибутов;

проведение атрибутного анализа и оптимизация сущностей;

идентификация отношений между сущностями и определение типов отношений;

разрешение неспецифических отношений;

анализ и оптимизация информационной модели.

3) Разработка событийной модели предприятия:

идентификация перечня состояний модели и определение возможностей переходов между состояниями;

определение условий, активирующих переходы, и действий, влияющих на дальнейшее поведение;

анализ и оптимизация событийной модели.

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

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

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

Ниже приводятся некоторые основополагающие рекомендации по структурированию моделей деятельности.

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

2) Верхний уровень модели должен отражать только контекст системы - взаимодействие моделируемого единственным контекстным процессом предприятия с внешним миром и ничего более. В случае построения модели структуры, включающей в себя несколько разнотипных предприятий, на контекстном уровне необходимо отразить каждое из них и их соответствующие взаимосвязи. Например, контекстная диаграмма горно-обогатительного комбината может содержать процессы Автобаза, Карьер, Фабрика и Управление ГОК, контекстная диаграмма регионального банка Сбербанка РФ содержит процессы Территориальное Управление, Типовое Отделение, Типовой Филиал.

3) На втором уровне модели должны быть отражены основные деятельности предприятия и их взаимосвязи. Например, для автотранспортного предприятия одним из решений может быть выделение следующих деятельностей:Эксплуатация автотранспорта, Ремонт и техническое обслуживание, Контроль безопасности, Управление производством, Обеспечивающая деятельность. В случае большого количества деятельностей некоторые из них можно вынести на третий уровень модели. Так Обеспечивающая деятельность может включать в себя Учет кадров, Бухгалтерский учет, Экономическое планирование, Материально-техническое снабжение, Складской учет и т.п. Но в любом случае под деятельности необходимо отводить не более двух уровней модели.

4) Каждая из деятельностей, в свою очередь, должна быть детализирована на бизнес-процессы (желательно, единственного уровня). Например, деятельность по учету кадров включает в себя бизнес-процессы Прием на работу, Увольнение и т.п.

5) Дальнейшая детализация бизнес-процессов осуществляется посредством бизнес-функций. Так процесс Прием на работу содержит в себе функции Прием заявления, Оформление приказа, Регистрация и др. Обычно для моделирования бизнес-функции достаточно 2-3 уровней детализации, которая завершается описанием элементарного алгоритма с помощью миниспецификации.

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

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

Первый пример касается автобазы, входящей в состав горнообогатительного комбината и занимающейся перевозкой породы от нескольких территориально разделенных предприятий по добыче руды (карьеров) на аналогичные предприятия по ее обогащению (фабрики). Парк автобазы содержит около 200 самосвалов “БелАЗ” грузоподъемностью 120 тонн, работы по перевозкам осуществляются в 3 смены. На каждую смену водителю выписывается путевой лист, содержащий 52 графы для однократного заполнения (хотя реально не все заполняются), при этом 5 граф заполняются многократно в соответствии с количеством погрузок/разгрузок. Кроме этого, на каждом путевом листе должно быть проставлено 17 подписей самых различных лиц, прежде чем он попадает в бухгалтерию автобазы и на его основе производится расчет соответствующих выплат. Даже если на получение каждой подписи и заполнение графы затратить в среднем по одной минуте, то оформление одного путевого листа (не включая его обработку в бухгалтерии) занимает более часа, а в день таких листов в принципе может быть шестьсот! Конечно, руководство автобазы прекрасно понимало проблему и ставило задачу сократить количество подписей хотя бы до 9-10. После проведения обследования и построения и анализа моделей выяснилось, что ВСЯ ИНФОРМАЦИЯ, за исключением контроля состояния водителя и, частично, самосвала (техническая исправность, медицинский контроль), ДУБЛИРУЕТСЯ в различных первичных документах (прежде всего, в диспетчерской сводке, ведомостях на выдачу талонов и различных накладных на отпуск горючего, масел и т.п.), то есть по своей сути путевой лист является производным документом! После предоставления таких результатов с резюме об уничтожении путевых листов как класса у руководства оставался единственный аргумент - требования ГАИ. Но, позвольте, для таких большегрузных самосвалов требуются специальные дороги, да и ездят они по четко определенным маршрутам карьер-фабрика. Более того, у них отсутствует государственный номер, весь учет ведется в соответствии с гаражным номером (от первого до двухсотого), не говоря уже о том, что за все время длительных командировок автору не встретился ни один инспектор.

Второй пример относится к распределенной диспетчерской службе того же самого комбината. Фактически имеется 8 диспетчерских пунктов (2 автобазы, 3 карьера, 2 фабрики, контора), на которых собирается и сводится одна и та же информация по перевозкам породы: карьер собирает данные по вывозу, фабрика - по разгрузке, автобаза - по перевозке, контора - всю эту информацию по каждому из предприятий, то есть одни и те же данные фиксируются 4 раза! Более того, все эти данные не совпадают, это связано со спецификой производства: например, в сырую погоду при разгрузке на кузов самосвала может налипнуть до 5 тонн породы! А поскольку объемы перевозок оказывают существенное влияние на начисляемую зарплату, все эти 8 диспетчеров ежедневно тратят уйму времени, сил и нервов на согласование этих данных (и в конце концов находят компромиссное решение). А дальше начинается самое интересное: с определенной периодичностью (неделя, месяц) специалист-маркшейдер делает замеры, сравнивает их результаты с предыдущими и выдает информацию по вывезенной породе за соответствующий период. И именно эта информация служит основой для начисления зарплаты и формирования отчетов по деятельности!

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

12.2. Разработка системного проекта

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

Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?". Именно здесь лежит ключ к успеху всего проекта автоматизации. В практике создания больших программных систем известно немало примеров неудачной реализации именно из-за неполноты и нечеткости определения системных требований.

На этом этапе определяются:

архитектура системы, ее функции, внешние условия ее функционирования, распределение функций между аппаратной и программной частями;

интерфейсы и распределение функций между человеком и системой;

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

состав людей и работ, имеющих отношение к системе;

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

В рамках системного проектирования должно быть осуществлено:

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

определение состава и структуры программных средств автоматизации технологии решения задач с учетом существующих средств в структурных подразделениях;

определение структуры и характеристик информационного обеспечения технологии решения задач;

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

разработка состава автоматизируемых процедур документооборота.

Системный проект должен включать:

полную функциональную модель требований к будущей системе;

комментарии к функциональной модели (спецификации процессов нижнего уровня в текстовом виде);

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

концептуальную модель интегрированной базы данных (пакет диаграмм);

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

предложения по оргштатной структуре для поддержки системы.

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

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

описать, "увидеть" и скорректировать будущую систему до того, как она будет реализована физически;

уменьшить затраты на разработку и внедрение системы;

оценить разработку по времени и результатам;

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

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

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

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

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

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

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

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

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

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

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

На данном уровне введены накопители данных, используемые в нескольких подсистемах и являющиеся прообразами подсхем интегрированной базы данных автобазы:

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

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

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

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

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

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

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

Рис. 12.1. Фрагмент системного проекта