Методология адаптивного визуального проектирования

 

МЕТОДОЛОГИЯ АДАПТИВНОГО ВИЗУАЛЬНОГО ПРОЕКТИРОВАНИЯ

 

Шведенко В.В., к.э.н., руководитель проекта ЗАО «Регул»

Реализация задач построения автоматизированных объектно-функциональных систем управления предприятиями (организациями/ учреждениями) разного уровня иерархии и информационной поддержки принятия управленческих решений обуславливает необходимость использования  методологии гибкого проектирования, легко перестраивающей  информационные объекты и запросы к ним под динамично меняющиеся условия внешней среды. Как правило, такие изменения происходят непрерывно, а значит, количество настроек системы, должно производиться достаточно часто.
    Кроме того, методология гибкого проектирования должна быть ориентирована на создание информационных систем ERP и BPM-классов, опирающихся на принципы процессного управления и возможность отслеживания изменений в момент их возникновения, а также по факту достижения запланированных результатов через систему сбалансированных показателей. 
    Желательно также, используя данную методологию проектирования, обеспечивать модификацию развивающих ее контуров самими пользователями системы (так называемыми «прикладными» специалистами), а участие программистов свести к минимуму.
    Еще один из немаловажных факторов – стоимость проектирования и развития информационной системы, которая должна находиться в диапазоне средних цен и быть доступной предприятиям малого и среднего бизнеса.
    Всем этим требованиям соответствует методология, предлагаемая ЗАО «Регул», получившая название «методология адаптивного визуального проектирования» и положенная в основу моделирования прикладных задач в программном комплексе «COBRA++».
    В основе данной методологии лежат четыре  базовых принципа ее реализации: принцип адаптивности, принцип визуальности, принцип системного единства и принцип развития.
    Принцип адаптивности выражается способностью осуществления быстрой перестройки  информационной системы от одной версии к другой и возможностью мгновенного восстановления предшествующего изменению функционала системы без потери каких-либо ее свойств. Также этот принцип позволяет легко создавать новые модификации функциональных блоков и обеспечивать обращение к ним через систему логических выборок.
    Принцип визуальности реализуется через возможность построения и просмотра элементов проектируемой, модифицируемой или эксплуатируемой системы в режиме реального времени  с помощью следующих инструментов: построение многомерных таблиц и рассмотрение двухмерных их проекций в любом разрезе по своему усмотрению; построения иерархических древовидных структур с любым уровнем вложенности и разветвленности;  построитель шаблонов экранных форм, обеспечивающих различный уровень доступа к данным;  интерактивный построитель запросов, обеспечивающий выборку данных по объектам разного уровня вложенности для поддержки принятия управленческих решений.
    Принцип системного единства обеспечивается работой с единым хранилищем данных, параметры которых могут быть скомбинированы между собой  самым разнообразным образом, при этом созданные конструкции сложных взаимосвязанных объектов не искажают характеристик друг друга, не создают дополнительное количество хранимых экземпляров, моментально формируются  через систему запросов в ту или иную выборку. Все построенные в системе объекты и созданные на их основе информационные массивы могут быть соединены с внешними базами данных, которые в совокупности  расширяют возможность проведения многомерного анализа данных и формирование прогнозных сценариев развития событий.
    Принцип развития позволяет наращивать функционал системы при сохранении целостности ее структуры.
    Несмотря на гибкость получаемых результатов, сама структура построения системы  требует соблюдения ряда формализованных правил.
    Правило 1. Систему желательно  строить сверху вниз, от первого лица компании. В этом случае обеспечивается  четкая установка и распределение между нижестоящими уровнями иерархии задач и показателей результативности. Это же позволяет отследить весь процесс развертывания информационной системы и собираемых показателей в соответствии с требованиями первых лиц компании, и установленными стратегическими ориентирами развития бизнеса.
    Однако, это  правило не означает, что систему нельзя  строить снизу вверх, или с какого-нибудь наиболее проблемного участка, а потом интегрировать с другими компонентами системы. Такая возможность существует.
    Правило 2. Система должна обеспечивать для владельца бизнеса (и при необходимости быть скрытой от других пользователей системы) абсолютную «прозрачность»  принимаемых бизнес-решений, опираясь на систему сквозного контроля в различных центрах ответственности.
    Однако, данное правило не означает, что система является строго иерархичной и закрытой для менеджеров разного уровня. Перераспределение ответственности за принятие управленческих решений предполагает создание динамических сетевых структур и возможность просмотра контролируемых показателей по мере увеличения степени ответственности за принимаемые управленческие решения. Просмотр показателей возможен при этом только сверху вниз, на подчиненные ему ветки организационного управления или по горизонтали в рамках его полномочий, осуществляемых по цепочке того или иного бизнес-процесса.
    Правило 3. Система должна обеспечивать отклик в режиме реального времени на возмущающие отклонения по всей цепочке ответственных исполнителей для принятия управленческого решения.
    Однако, если системой предусмотрены регламенты реагирования на возмущающие воздействия,  сигналы оповещения о проблемной ситуации и контроль за ее решением, доводятся до ответственных исполнителей через календарь событий. При этом ведется хронология (мониторинг) реагирования исполнителей на поставленные перед ними задачи.   Информация систематизируется и поступает в виде отчета вышестоящим руководителям, на основе которого происходит оценка деятельности сотрудника (подразделения).
    Правило 4. Система развивается на основе создаваемого тезаруса объектов, процессов и показателей описывающих  предметную область. Тезарус представляет собой набор свойств, объектов, действий, функций, названий показателей и т.д. Он является методологической предметной платформой создаваемой информационной системы, за пределы которой выходить не допустимо.
    Однако, в случае необходимости, предметная область может быть расширена. Система отслеживает авторскую корректировку тезаруса.
    Правило 5. Каждый создаваемый информационный блок системы должен обладать всей полнотой функционала, необходимого для его создания, эксплуатации и сопровождения.
    Однако, данное правило не означает, что каждый пользователь системы будет иметь доступ ко всем его модулям или функциям в рамках конкретного модуля. Система позволяет гибко управлять доступом к информации и функциям ее преобразования.
    Правило 6. Информационная система создается ее пользователями. Но контур системы, связи между объектами, контролируемые показатели назначаются архитектором информационной системы. В качестве архитектора системы могут выступать высококвалифицированный специалист (специалисты) предметной области, являющийся сотрудником предприятия или внешние консультанты.
    Процедура архитектурного построения информационной системы предприятия состоит из следующих трех основных блоков:

Блок 1 - Построение ресурсной, организационной и учетной моделей предприятия - cоздание паспорта предприятия (справочники, регламенты, положения, схемы).

Блок 2 -  Построение каркасной модели бизнеса предприятия и анализ прогноза ее эффективности:

  • Описание предприятия и его окружения;
  • Стратегический анализ. Описание общей и функциональных стратегий;
  • Декомпозиция целей, задач, инициатив. Дерево ССП. Дерево КPI;
  • Распределение ответственности структурных подразделений за бизнес-процессы и функции предприятия;
  • Построение модели бизнес-деятельности (бизнес-план) и оценка ожидаемых результатов;

Блок 3 – Построение процессной и бюджетной моделей предприятия и запуск  мониторинга системы:

  • Формализованное описание бизнес-процессов в разрезе направлен-ной функциональной (основной и вспомогательной) и учетно-аналитической деятельности;
  • Построение финансовой структуры предприятия;
  • Создание центров финансовой ответственности (ЦФО) и центров финансового учета (ЦФУ). Распределение статей БДР, БДДС, БДА по ЦФО;
  • Привязка бизнес-процессов к ЦФО;
  • Запуск  бизнес-процессов. Мониторинг исполнения бизнес-процес-сов.

 

Схематично работа информационной системы показана на рис. 1:

 

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


Таким образом, предлагаемая к рассмотрению методология адаптивного визуального проектирования позволяет одинаково эффективно развернуть информационную систему для реализации задачи любой сложности и предметной направленности, что создает предпосылку  построения единой информационной среды управления как в разрезе отдельных предприятий, так и объединяющих их корпораций.
     
Список используемой литературы:
     1. Шведенко В.Н., Набатов Р.А., Щекочихин О.В. Адаптивная автоматизированная система проектирования и управления бизнес-процессами// Приборы и системы. Управление, контроль, диагностика, №6, 2008, с.59-60
     2. Щекочихин О.В., Терская Н.А. Адаптивно-поисковый метод управления организационно-техническими процессами в корпоративных информационных системах/ Современные проблемы прикладной информатики. Сборник научных трудов. Под ред. Брусакова И.А., Панова Е.Н., Изд-во политехнического университета г.С-Петербург, 2009, с. 72-76.
     3. Шведенко В.Н., Шведенко В.В., Богданова Е.А., Виноградова Г.А., Терская Н.А., Набатов Р.А., Щекочихин О.В. Введение в программный комплекс «COBRA++»  и технологию предметного визуального адаптивного проектирования. Учебно-методическое пособие под общ. Ред. Д.т.н., проф. Шведенко В.Н., Издательство Общество «Знание» России, Кострома, 2009 – 112 с.