Инженерное решение проекта развития — это производственное предпринятие.

Не забываем, что стейкхолдер — это только роль. Исполнитель разных ролей может быть одним и тем же человеком (или предпринятием — проектной командой, рабочей группой, подразделением). Так что одни и те же люди могут и заниматься и производством, и совершенствованием, и развитием. Одной и той же ручкой, одним и тем же Word можно писать тексты и по проектам развития, и по производственным проектам. Но ввиду глубокого разделения труда вполне возможны ситуации, когда главными в развитии будут не-производственники, а специально выделенные люди: отдел развития, приглашённые консультанты. Конечно, производственники тоже участвуют при этом в работе, но они будут… рабочими продуктами. Помним о лидерстве (leadership): это дисциплина, которая позволяет людям добровольно становиться рабочими продуктами в проектах развития и не менее добровольно занимать позиции в производственных (целевых) проектах. Именно лидерство объединяет инженерию предпринятия как инженерную дисциплину и традиционный менеджмент как социологическую и психологическую дисциплину.

Организационное развитие. Закон Конвея

Закон Конвея (http://www.melconway.com/Home/Conways_Law.html) утверждает,

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

спроектированный самолёт не взлетит.

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

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

Современные предпринятия меняются непрерывно. Вот визуализация подобной перманентой реорганизации для Autodesk, отражающая постоянные кадровые перестановки, позволяющие компании выдерживать конкурентоспособность продуктной линейки: http://www.youtube.com/watch?v=mkJ-Uy5dt5g

Видеоролик воспроизводит 1498 дней организационной иерархии компании Autodesk (с мая 2007 по июнь 2011), каждая секунда — это примерно одна неделя. Каждый сотрудник представлен кружком, бОльшие кружки обозначают сотрудников с бОльшим числом подчинённых. Каждая линия означает подчинённость одного сотрудника другому (кто чей начальник), дерево подчинения дальше анимировано, чтобы показать изменения (полная информация по проекту — http://www.autodeskresearch.com/projects/orgorgchart). Видео там высокого разрешения, смотрите на максимально доступном разрешении.

Не нужно думать, что такой темп кадровых перестановок некомфортен для работников, у которых постоянно меняется их подчинённость и вовлечённость в разные проекты. Autodesk занимает 54 место в списке Fortune 100 компаний-лучших работодателей, http://money.cnn.com/magazines/fortune/bestcompanies/2013/snapshots/54.html — несмотря на эти постоянные кадровые перестановки.

Конечно, чтобы поддерживать порядок при таком темпе изменений, необходимы компьютерные системы — именно они помнят, кто кому когда подчинялся, кому какую платить зарплату, кто когда уходил в отпуск, кто на какой проект работал. Лет двадцать назад про IBM писали, что одновременно в любой момент в ней идут в среднем 35 проектов реорганизации, и это число казалось запредельно большим, а опыт IBM уникальным. Сегодня это уже поддержанная компьютерами норма жизни, так живут уже все крупные компании.

Упражнение: для тех компаний, в которых вы работали, подумайте: хватит ли информации в компьютерной системе предприятия, чтобы сделать такую визуализацию хода перестановок, какую сделал Autodesk? Какой темп организационных изменений в этой организации? Какой темп смены продуктных линий, сопровождается ли он реорганизациями?

Системноинженерное мышление и инженерия предпринятия

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

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

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

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

Конечно, терминология отличается (хотя стейкхолдера назовут стейкхолдером и архитектуру архитектурой), но мы не зря тренировались абстрагироваться от конкретных слов и больше заниматься смыслом говоримого.

Тем самым весь материал предыдущих разделов вполне применим для обсуждения предпринятия.

Совершенствование предпринятия — это необходимость практиковать какую-то ступень зрелости практик, чтобы получить хоть какой-то шанс шагнуть вперёд, на следующую ступень развития. Совершенствование зрелой уже практики — это часто путь к загниванию, это прекращение развития. После того, как вы довели до блеска бумажный документооборот, у вас могут быть огромные проблемы с развитием в сторону электронной коллаборации, ибо там не просто "электронный документооборот", но проблемы с самим понятием документа как универсальной сущности — речь ведь идёт главным образом о совместной работе разных приложений с общими базами данных! Отказаться от документов в этот момент — это будет восприниматься не как развитие, а как махровое антисовершенствование, разрушение основ и крах того совершенства, которым нужно гордиться! Совершенное воспринимается, как лучшее, а результат развития — только как хорошее (ибо всем очевидно, что этому ещё совершенствоваться и совершенствоваться, чтобы сравниться с уже имеющимся). "Хорошее — враг лучшего!" — и развитие прекращается, не начавшись. Старые парадигмы, старые cognitive frameworks умирают только с их носителями...

Первый шаг решения проблемы "развитие против совершенствование" — это возможность её коллективного (ага, в том числе в коллективе с самим собой! Попробуйте написать ваши мысли, а затем прочесть — и при написании, и при прочтении вы откроете для себя много нового!) обсуждения.

Для самой возможности обсуждения совершенствования и развития нужно опереться на системноинженерное мышление. Harold Lawson писал в комьюнити

INCOSE в LinkedIn в треде "Building SE into an Organization", — "...it is all about understanding and communication. If you do not get people on the same page you are simply talking in the air. That is why learning fundamental paradigms, concepts and principles of systems is so important". Развитие начинается в тот момент, когда его

можно обсуждать, когда выучен язык, на котором говорят о развитии. Нужно освоить "fundamental paradigms, concepts and principles of systems" — и пройти ступеньку совершенствования, чтобы научиться этим пользоваться. Нужно сделать шаг "развития для развития". Это трудно: прекратить индивидуальное или корпоративное совершенствование в том, чем вы прямо сейчас сами или с коллегами заняты, и пройти ряд образовательных ступенек, которые с точки зрения текущей ступеньки "ни о чём".

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

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

Цикл непрерывного совершенствования

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

В книге Элияху Голдратта “Цель: процесс непрерывного совершенствования” и в других книгах этого автора (ознакомительные экземпляры вы можете найти тут: http://rutracker.org/forum/viewtopic.php?t=2403312 — не забудьте потом купить эти книги!) показывается, как работать с логистической метафорой “потока” в операционном управлении: предприятие представляется чем-то типа дельты реки, со множеством ручейков, запруд, каналов, перетоков — там, где стоит “запруда” (по разным причинам медленно пропускающее через себя рабочие продукты организационное звено),там образуется “очередь на обработку” — и необходимые для включения в состав готовой целевой системы рабочие продукты застревают в этой очереди, задерживая готовность целевой системы в целом.

Главная задача менеджера (операционного управляющего) — это непрерывно прочищать “запруды”, максимально влияющие на задержки по выпуску основной системы. Главная задача — это увеличение “прохода” (протока) через предпринятие, ибо если целевые системы (оказываемые сервисы) будут быстрее и в большем количестве уходить, то и деньги за них будут приходить быстрее и в большем количестве (про особенности управленческого финансового учёта в теории ограничений см. книгу Томаса Корбета “Учёт прохода”/”Throughput accounting”).

В ходе выполнения работ по множеству проектов предпринятия вы должны находиться в цикле непрерывных улучшений: