«Как правильно «строить» или «перестраивать» предприятие?»
Один из основных выводов в том, что то большинство проблем предприятий вытекает из того, что людей заставляют работать в плохо спроектированных организациях.
Не секрет, что большинство менеджеров даже не задаются вопросом о наличии методологии или лучшей практики по строительству предприятия и все делают по наитию.
Скорее всего, предприятие формируются как придется, а в лучшем случае с использованием предыдущего опыта членов коллектива, и с опорой на часто несовместимые компетенции ключевых сотрудников, придерживающихся разных школ менеджмента.
В нашей методологии #системныйменеджмент мы опираемся на такое понятие как #архитектурапредприятия, ведь для того чтобы "построить" или "перестроить" предприятие нужно очень хорошо понимать его архитектуру.
Архитектура -- это набор самых важных инженерных решений.
Важные инженерные решения -- это при изменении которых придётся перепроектировать бОльшую часть инженерного объекта.
Поэтому важные решения по устройству предприятия -- это при изменении которых придётся переустраивать бОльшую часть предприятия. Они и называются архитектурными решеними.
Если вы поменяли в самолёте винтик с одного на другой, то изменения коснутся только этого винтика -- это не архитектурное решение.
Если вы поменяли двигатель с турбореактивного на реактивный, или решили делать фюзеляж и крылья из композитных материалов, то вам придётся перепроектировать почти всё -- это будет архитектурное решение.
Все тоже самое и в деятельности предприятия: необходимо делить все решения на архитектурные и неархитектурные. И где заканчиваются архитектурные (важные) решения знает только сам архитектор системы (системный инженер).
Вот еще несколько смыслов, которые раскрываются в нашей методологии:
1. Архитектура предприятия выражена в архитектурном описании. При этом очень важно определить метод описания. Метод описания должен предусматривать тот факт, что описания также должны удовлетворять разным интересам стейкхолдеров, а поэтому описаний будет много.
2. Инженерия предприятий сегодня предусматривает строительство предприятия по информационным моделям предприятия, точно так же, как и дома строят сейчас по информационным моделям здания. В инженерии предприятий главное поэтому -- навыки системного описания деятельности, принятия системных решений и отражение их в информационной модели, в архитектуре предприятия. Это самое сложное - уметь видеть и понимать целостное устройство организации. Инженерия предприятия - это не моделирование процессов деятельности предприятия. Это лишь его небольшая часть.
3. Архитектура – это всегда синтез, это сбор всех частей, а аналитика – это наоборот, деление всего на части и описание их. В архитектурной работе участвуют разные роли: бизнес-аналитик, архитектор предприятия, бизнес-архитектор, управление процессами и служба качества, сотрудник ИТ-службы. Но чтобы проводить архитектурную работу нужны соответствующие полномочия! Лучше всего когда архитектор предприятия подчинен 1-му зам.Генерального директора, а не CIO, тк в этом случае вместо архитектуры предприятия придется заниматься ИТ-архитектурой.
4. Архитектура предприятия – это архитектура деятельности, а бизнес архиктектура – это бизнес модель, стратегия. Поэтому в первом случае у нас практики, проекты-процессы-контрольные точки, роли-структура подразделений (органиграмма), ИТ-поддержка деятельности. А во втором случае – это понимание кому нужен продукт (полезность, ценность), справимся ли мы, кто партнеры, на каких рынках работаем, и т.п.
5. Архитектура предприятия часто может быть под другими именами: организационная модель, оргфункциональная модель. А вот следующие понятия являются лишь частью архитектуры: органиграмма, бизнес-архитектура, бизнес-процессы, вид жизненного цикла, архитектура ИТ-решения.
6. Регламенты деятельности генерируются автоматически из архитектуры предприятия, а не наоборот, т.е. архитектурное описание предприятия не восстанавливается из регламентов. Например, в некоторых архитектурных моделерах регламенты автоматически генерируются из модели архитектуры предприятия. Прогрессивная практика деятельности – это когда в организации совсем нет регламентов, а все сотрудники знают архитектуру своего предприятия прямо по архитектурным диаграммам из моделера.
7. Лучшее архитектурное решение – это с хорошей модульностью. Всё предприятие должно состоять из организационных звеньев-модулей, которые являются предоставляют стандартные оргсервисы на хорошо известных интерсфейсах (каналах взаимодействия -- по почте, лично, через информационные системы, через конвейер, и т.д.). Организация, сформированная из таких модулей с хорошими интерфейсами будет гибка, быстра и легко перестраиваема в ходе шагов развития и циклов улучшений.
8. Если вы решите поменять корпоративный софт (например, PLM, ERP, EAM системы), то это бесполезно делать, если вы не поменяете также и организацию работы людей. К сожалению, в большинстве случаев менеджеры абсолютно не думают будет ли это решение архитектурными или нет. Также многие менеджеры еще не понимают, что если они решили менять организацию работы людей, то это бесполезно делать без адекватной поддержки софтом: в 21 веке иначе просто не справиться со сложностью выполняемых работ. Например, вы решили поменять поставщика PLM-системы -- это архитектурное решение, это существенно поменяет организацию работы ваших инженеров, ваше предприятие существенно изменится.
9. Основная цель архитектурного моделера – это показать на одной диаграмме объекты интереса бизнеса и ИТ (софта и железа) и ответить на вопрос: КТО С ЧЕМ ЧТО ДЕЛАЕТ? Также моделер полезен для вгрызания в детали одного уровня деятельности, коммуникации между ответственными за разные уровни деятельности и для облегчения работ по распределению практик по организационным звеньям так, чтобы предприятие было высокомодульным.
10. Важна не сама архитектурная модель, а те решения, которые она отражает. Великолепное архитектурное описание на лучшем архитектурном языке может отражать очень плохие организационные решения, и наоборот.
11. Учиться моделировать архитектуру предприятия нужно с маленьких моделей, потихоньку их расширяя (тут как в программировании: программы пухнут медленно, но неуклонно. Также и ваша модель будет расти постепенно, но неуклонно). И не забывайте об управлении конфигурацией (т.е. следить за версиями модели и контролировать, кто вносит в неё изменения).
12. Органиграмма – это то, что с интересом любят все обсуждать, так как в ней отражаются полномочия, но главное в ней – это документирование организационных звеньев как модулей.