Завершение публикации. С первыми 2 частями материала вы можете ознакомиться по ссылкам:
Построение верхнероувневой модели деятельности компании на основе принципов системной инженерии. Глава 1. Процессы или функции?
Построение верхнероувневой модели деятельности компании на основе принципов системной инженерии. Глава 2. Делим организацию на части
Каждая система, выделенная в предыдущей главе, осуществляет свою специфическую деятельность, которая представляется в виде отдельной IDEF0-модели. Принципы, которых мы будем придерживаться при моделировании, изложены в следующей главе.
В данной главе приведены мои личные рекомендации по изменению нотации, которые будут нашим «Соглашением о моделировании».
Необходимо использовать стрелки «Механизмы» только тогда, когда это реально необходимо для отображения состава подсистемы, реализующей функцию. Например, когда необходимо подчеркнуть, что подсистема собирается ситуативно «по потребности» для реализации конкретной задачи, а потом разбирается. Например, для проекта. В регулярной же деятельности в большинстве случаев подсистема для реализации функции уже собрана:
В предлагаемой концепции это делается в Системе развития, а ремонтируются или заменяются части системы в Обслуживающей системе. Поэтому постоянный состав средств деятельности, включая персонал, в Business Studio целесообразно указать в свойствах функции и разгрузить схему.
Принцип декомпозиции на первом уровне: жизненный цикл системы.
В рамках Системы развития Обслуживающая и Обеспечивающая системы проходят часть стадий своего ЖЦ: Замысел, Разработка, Производство.
Продукты проходят стадии «Замысел» и «Разработка» в определенной части в зависимости от отрасли и серийности производства (см. примеры выше).
В модель встроено два принципа запуска работ:
Принцип декомпозиции на первом уровне: Глобальная "технологическая" цепочка.
Этапы:
Принцип декомпозиции на первом уровне: по видам средств деятельности.
Выделяются следующие виды средств деятельности, обращение с которыми имеет свою специфику:
Принцип декомпозиции на втором уровне: по жизненному циклу средства деятельности.
Стадии ЖЦ объекта:
Между системами есть интерфейсы. Например, документация на оборудование, поступающая из Системы развития в Обслуживающую систему.
Business Studio позволяет моделировать их с помощью междиаграммных ссылок.
Если функция нужна нескольким системам и она одинакова в рамках этих систем, то ее можно «централизовать» в одной из систем. В представленном примере это сделано для функции «Финансирование деятельности» (включая бухгалтерский учет) для Операционной и Обслуживающих систем. Функция помещена в Операционную систему. Обслуживающая система имеет к ней доступ через интерфейс, смоделированный с помощью междиаграммных ссылок.
Функция «Финансирование деятельности» Системы развития в данном примере пусть будет уникальной. Плюс сама Система развития может быть представлена отдельным юридическим лицом, поэтому она «заслуживает» свою собственную функцию.
Допустим нам необходимо закупать ресурсы и оборудование в рамках нескольких имеющихся в моделях Операционной и Обслуживающей систем функций. У нас есть закупка:
Раньше мы нарушали естественную последовательность работ и все запросы на поставку сводили в единую функцию «Закупка». Т. е. теряли понятность модели. При этом вдобавок обретали сложность общей модели, потому что все-таки закупка для разных деятельностей может иметь свою специфику. Теперь у нас есть выбор: мы ставим функцию «Закупку» там, в тех системах, где она нужна. Если она выполняется полностью по одинаковым правилам, то мы используем ссылку на типовую модель. Если она имеет специфику, то мы ее показываем в подфункциях, где она есть. А где ее нет — используем ссылки на типовую модель подфункции.
При этом типовые функции нужно своевременно распознавать и создавать их реестр в отдельной папке модели.
С точки зрения организационной структуры исполнителями функций во всех системах могут являться оргединицы одной оргструктуры. В системной инженерии допустимо, когда один компонент системы реализует несколько функций. Это принцип проявляется, например, при назначении руководителей на функции и процессы Системы развития и Операционной (Обслуживающей) системы. Этим подчеркивается факт, что каждый руководитель должен отвечать и за развитие, и за операционный уровень. Оргединицы назначать исполнителями можно непосредственно или через роли.
Если же за развитие отвечает отдельная организация, например, управляющая компания холдинга, то исполнителями функций системы развития будут являться оргединицы из оргструктуры управляющей компании.
Мы закончили рассмотрение предлагаемого фреймворка. Его важной особенностью является выделение на верхнем уровне трех принципиально разных видов деятельности внутри компании: развития, операционной деятельности и обслуживания. Это позволяет:
Август 2021 г.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
Введите поисковый запрос:
Сообщение успешно отправлено