Построение верхнеуровневой модели деятельности компании на основе принципов системной инженерии. Глава 3. Фреймворк деятельности компании

Публикации
Поделиться:

Дмитрий Пинаев

Генеральный директор ГК «Современные технологии управления»

Завершение публикации. С первыми 2 частями материала вы можете ознакомиться по ссылкам:
Построение верхнероувневой модели деятельности компании на основе принципов системной инженерии. Глава 1. Процессы или функции?
Построение верхнероувневой модели деятельности компании на основе принципов системной инженерии. Глава 2. Делим организацию на части

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

Модификация нотации IDEF0

В данной главе приведены мои личные рекомендации по изменению нотации, которые будут нашим «Соглашением о моделировании».

Класс стрелок «Управление»

  1. Стрелки «Управление» в первую очередь используются для моделирования объектов, запускающих процессы на нижнем уровне модели (планы, задания) в том случае, когда для инициации не используется сам факт появления объекта на входе (см. п.2).
  2. В случае наличия единственного трансформируемого объекта на входе, я не согласен с требованием стандарта указывать объект, как стрелку «Управление». Я использую стрелку «Вход».
  3. Регламенты не показываются как стрелки «Управление». Мы не моделируем в рамках «производственной» функции как сотрудники читают регламенты. Сотрудник к моменту выполнения процесса должен быть уже подготовлен к работе и знать их. Чтение регламентов происходит либо при сборке Операционной или Обслуживающей системы в Системе развития, либо при приеме новых сотрудников на место уволенных в Обслуживающей системе.
    Если необходимо, регламент вместе с другими справочными документами можно приложить в свойства процесса в среде моделирования.

Класс стрелок «Механизмы»

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

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

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

Модель Системы развития

Принцип декомпозиции на первом уровне: жизненный цикл системы.

В рамках Системы развития Обслуживающая и Обеспечивающая системы проходят часть стадий своего ЖЦ: Замысел, Разработка, Производство.

Продукты проходят стадии «Замысел» и «Разработка» в определенной части в зависимости от отрасли и серийности производства (см. примеры выше).

В модель встроено два принципа запуска работ:

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

Модель Операционной системы

Принцип декомпозиции на первом уровне: Глобальная "технологическая" цепочка.

Этапы:

  • Клиента нужно привлечь и продать ему продукт;
  • Закупить необходимые ресурсы;
  • Произвести продукт;
  • Оказывать послепродажный сервис.

Модель Обслуживающей системы

Принцип декомпозиции на первом уровне: по видам средств деятельности.

Выделяются следующие виды средств деятельности, обращение с которыми имеет свою специфику:

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

Принцип декомпозиции на втором уровне: по жизненному циклу средства деятельности.

Стадии ЖЦ объекта:

  • Запланирован к ремонту/замене;
  • Закуплен/привлечен с рынка труда;
  • Интегрирован в инфраструктуру/обучен;
  • Списан.

Особенности техники моделирования отдельных систем

Использование междиаграммных ссылок между моделями систем

Между системами есть интерфейсы. Например, документация на оборудование, поступающая из Системы развития в Обслуживающую систему.

Business Studio позволяет моделировать их с помощью междиаграммных ссылок.

Использование единых «сервисных» функций

Если функция нужна нескольким системам и она одинакова в рамках этих систем, то ее можно «централизовать» в одной из систем. В представленном примере это сделано для функции «Финансирование деятельности» (включая бухгалтерский учет) для Операционной и Обслуживающих систем. Функция помещена в Операционную систему. Обслуживающая система имеет к ней доступ через интерфейс, смоделированный с помощью междиаграммных ссылок.

Функция «Финансирование деятельности» Системы развития в данном примере пусть будет уникальной. Плюс сама Система развития может быть представлена отдельным юридическим лицом, поэтому она «заслуживает» свою собственную функцию.

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

Допустим нам необходимо закупать ресурсы и оборудование в рамках нескольких имеющихся в моделях Операционной и Обслуживающей систем функций. У нас есть закупка:

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

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

При этом типовые функции нужно своевременно распознавать и создавать их реестр в отдельной папке модели.

Моделирование исполнителей

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

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

Резюме

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

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

Август 2021г.

Поделиться:

Рекомендуемые материалы по тематике