Обсуждение

Хммм... А я в принципе не уверен в возможности и необходимости применения в предложеной ситуации инструментальных методов. Собственно, в ситуации, когда "организация1 не вполне понимает, какая организация2 ей надобна" это же просто вопрос целеполагания и качества управленцев. Или я не прав?

А это вот что получилось, очень кратко и не заглядывая в книжки - компиляция из основных книжек, компиляция с переосмыслением, или все-таки собственная теория/модель/понимание, с поправкой на прочитанные книжки? Т.е., как мне к этому тексту относиться? Как к дайджесту того, что есть в современной научной мысли, или как к Вашему специфическому взгляду? Поскольку, если как к специфическому взгляду, то нужно искать столь же емкие и проработаные изложения каких-то других концепций, а если это хоть сколько-нибудь всеохватно, то можно читать этот текст в режиме обучения. Ибо текст хороший.

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

Я думаю, что неправ: вопрос просто сдвигается в сторону "качества управленцев" -- какой организационный репертуар этим управленцам доступен. Скажем, управленцам амазонских джунглей вряд ли доступно в их репертуаре классическое управление проектами, да они и слова-то такого "проект" не слышали, а про "реформы" у них четко отрицательное мнение, их долго воспитывают в любви к традициям, у них просто табу эти традиции изменять. Есть и другая грань этого вопроса: организация1 состоит из многих людей, у каждого может быть свое собственное понимание, какая организация2 этой группе надобна. Чтобы договориться, им нужно как-то сорганизоваться. И так далее: сто человек высококачественных управленцев, собравшись в одной комнате, могут очень долго и безуспешно решать, что они хотят сделать с десятком тысяч других человек, и как они для этого должны сорганизоваться...

Спасибо за комплимент. Все это, конечно, написано в разных книжках, "ничего личного" :) Что я сделал -- это собрал это в один текст, ибо в текстах про управление проектами не говорится обычно о программах, в текстах о программах -- об экстремальном управлении проектами, в текстах о социальной инженерии -- о контрактации и управлении ресурсами и т.д.

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

тут нет очепятки? kang

Есть :)

Вот я хотел спросить. Мы, например, сейчас разрабатываем систему управления бизнес-процессами. Т.е. вы формализуете процессы, а потом их исполняете. Очевидно, что если процессы неизвестны, то можно создавать процессы, которые формализуют или адаптируют процессы. Это называется BPMS. Мы делаем систему, которая не требует профессиональных бизнес аналитиков и компания может сама построить свои процессы постепенно в стиле RAD, при этом купив систему существенно дешевле чем коммерческие BPMS. Кроме того, наша система предполагает быть значительно более конкретной (BPMS как правило очень абстрактны - они позволяют сделать очень много, но выглядят набором запчастей или "заводом по производству заводов для производства молотков" для нормального пользователя). Так в ней можно просто создать задачу в стиле напоминания. И она будет работать (висеть). Потом добавить когда. Потом добавить кто. Потом добавить процесс. Потом описать вероятности и посмотреть WhatIf. Итд. Возможно, ваш пост был не об этом. А может и об этом. Что лично Вы думаете по поводу подобных систем (рынок таких систем уверенно растет и показывает очень хорошие ROI)? Потому что, например, система Мотив (про которую вы как-то говорили) - я ее изучил, это малопригодно для изменяющихся задач и сложных проектов. BPMS подразумевает также, что у вас часть задач это автоматические задачи (например изменить саму задачу или выписать накладную в другой системе).

Данный пост -- не про процессы (операции), и даже не про проекты, а про программы как таковые. А BPMS -- это про процессы. BPMS, конечно, должны быть. Их должно быть много и разных. К средствам их описания у меня много-много вопросов. Motiw, конечно, не панацея. Про BPMS у меня совсем другие постинги. BPMS не работают в ситуации, когда вам нужно сделать какую-нибудь общественную реформу или реорганизовать одно большое производство в сеть малых предприятий (или наоборот). А главный вопрос, который я буду задавать к BPMS -- это какой у нее планировщик, и как эта BPMS позволяет описывать как процессы, так и проекты (классические). А если планировщика у нее нет, то и разговор совсем-совсем другой. Для того, чтобы подойти к пониманию BPMS, нужно поднять вопрос об организационной модели. Процессы в этой модели лишь один из аспектов описания (а еще есть структуры, функции, морфология, материал). Об этом я неоднократно писал в других постингах.

Спасибо за ответ. Я, конечно, подозревал, что пост не о том, просто не нашел "того", а спросить давно хотел. Я не специалист по реформам и пока не берусь решать подобные задачи - поэтмоу спрашиваю о своем, насущном :) Т.е. о проектировании процессов, когда их вообще возможно понять и совершенствовать - смотреть как на практике сформулированные процессы соответствуют действительности и адаптировать. Что Вы понимаете под планировщиком? Возможность увидеть как задачи располагаются на временной оси? Это у нас есть - зная вероятности течения процессов мы можем построить наиболее вероятное расписание (с учетом календарей, пересечений, доступности людей и ресурсов с нужными зарактеристиками) и сказать наиболее вероятную стоимость. Процессы все предпочитают описывать диаграммами процессов - BPEL, BPMN и еще 7 стандартов. Суть их всех - нарисовать действия, соединить входы и выходы, добавить логических конструкций. Существует хорошая научная работа о необходимых паттернах процессов. Но мы решили пойти несколько другим путем описания процессов. Мы не рисуем диаграммы. У нас есть список процессов (где каждый процесс может сам содержать процесс), в котором мы связываем события (сделано, не сделано, отменено, пользователь утвердил, итд - в зависимости от типа задачи) с методами процессов (тоже в зависимости от типов - начать, отменить, отложить, установить данные, послать уведомление итд). В результате вместо диаграм мы имеем 2х уровневый список (в котором процесс называется задача): Задача1 если Закончилась -> начать Задача2 если Отменена -> начать Послать Уведомление об Отмене Задача2 если Началась -> начать Послать Уведомление о начале Задачи 2 Послать Уведомление о начале Задачи2 Ну грубо говоря так. Задачи настраиваются. Второй вход в задачу это второе исполнение. И справа от списка у нас гант - на нем рисуется план выполнения. В результате можно менять последствия процесса в результате повторного вхождения. Связывать можно только на 1 уровне. Но можно "вытаскивать" события на верх - тогда те кто используют процесс могут знать что-то о нем, при этом по-прежнему работая как с черным ящиком. Можно делать свои события на задачах - срабатывающие по определенным условиям - время или условия данных. Есть задачи типа "Ожидание" - позволяют объединять процессы в 1 - когда, например, нужно дождаться нескольких событий. В результате у нас процессы описываются не диаграммами а событиями-методами вместе с планом. В отличие от диаграмм мы можем работать с множественными исполнениями задачи по-разному. На диаграммах это было бы третье измерение, что, очевидно, никуда не годится - даже 2х мерные диаграммы часто выглядят неочевидно. Как Вам такой подход к описанию процессов? В системе есть наборы структур - организационная структура компании, структура квалификаций, структура географических мест (с типами и ценообразованием), структуры материалов и оборудования(аналогично). Задачи имеют роли и оперируют ролями (на них указываются требования к квалификациям и в результате возможен побдор агентов по загруженности, месту, квалификации). Существуют и просто объекты. Можно создавать классы объектов, описывать их, создавать сущности и оперировать ими во время процессов. Планирование как таковое, в системе это всего-лишь определенная вероятность. Иначе быть вроде как и не может - если неочевидно, что задачу надо будет выполнять, то вероятность не 100% и мы это можем честно сказать. А зная историю, мы можем уточнять эту вероятность. Как Вам кажется - это покрывает насущные нужды? И вообще выглядит понятным, логичным, сбалансированным? Понятно, что там где процессов нет "by design", там вообще проблемы с автоматизацией. Но все-же процессы формадизовать как-то надо, иначе очень трудно что-либо делать с ростом.

То, что вы описываете, занимает какое-то промежуточное положение между управлением процессами и управлением проектами и, похоже, является каким-то подходом к оргмоделированию. Как я понимаю, у вас "объект-ориентированное описание процессов/проектов, оргструктуры, персонала" и специальный язык программирования для этого. Планировщик (оптимизатор порядка выполнения работ, знающий об имеющихся ресурсах людей, денег, материалов и оборудования) у вас тоже какой-то есть. То есть у вас все выглядит как вполне нормальная система организационного моделирования (с точностью до того, что я понял), в которой организация моделируется в стиле объектно-ориентированного подхода. Дальше можно задавать вопросы про опыт использования этой системы не вами (не разработчиками) и о понятности ваших описаний для непрограммистов. Затем можно задавать вопросы об использовании построенной вами модели различными системами рендеринга (форматы представления, view), исполняющими системами -- т.е. наличествует ли у вас какой-то стандарт на язык описания организационной модели. Пока я знаю только одну фирму, которая имеет подобный заход на оргмоделирование и производит программные системы в этом направлении: это фирма БИГ. А теперь еще и ваша фирма...

Да, вы достаточно хорошо поняли. Специальный язык у нас отсутствует как класс. Есть возможность настроить соединения метод-событие. Есть возможность расширять типы задач написанием новых классов. Будет возможность писать некий код на C#/VB.NET/J#/C++ для своих типов задач и классов объектов. Есть некий язык условий проверки данных. Он в общем то VB/C#. От свои языков мы тщательно уворачиваемся. Но предполагаем, что большинство вещей можно будет сделать вообще без языка. И лишь в редких тяжелых случаях можно что-то дописать. Опыта использования этой системы нет. Потому что фактически это новая версия, которая меняет модель Task Management на BPM, но потребность в таком подходе выяснена из текущих клиентов. Языка описания орг модели у нас нет - это просто диалоги, свойства по дизайну задач. Но вполне вероятно, что мы будем экспортировать/импортировать модели из стандартных языков описания BP - если закрыть глаза на то, что ни один из них не реализует все ключевые паттерны описания процессов. Фирма БИГ - это www.big.spb.ru ? Я посмотрю, спасибо.

То есть вы пытаетесь говорить об оргмодели в терминах C#/VB.NET/J#/C++ -- а именно, у вас есть некая организационная онтология, но вы в явном виде организаторам ее описание не даете. А ведь самое интересное начинается тогда, когда с системой работают не программисты, а бизнес-аналитики совместно с менеджерами и даже просто исполнителями. Питерская фирма БИГ (их там несколько под этим именем), продукты ОргМастер (и в сильно меньшей степени ТаймМастер) -- только вряд ли вы поймете что-то из тамошних описаний, настолько они специфичны. Другое дело, что сам подход их представляется здравым, и хорошо работает. Увы, вместо нормальных описаний они передают "тайное знание" изустной традицией на семинарах. Но мы видели это дело в работе, вполне себе рабочий подход.

Нет мы не говорим в терминах C#. Мы просто даем возможность описывать без языка - настройкой процессов в диалогах. А вот там где надо сложные проверки или непредусмотренную логику - там пожалуйста, объектная среда 1-1 с реальными - можно добавлять свою логику. Практика показывает, что непрофессиональные пользователи не особо то любят вообще какие-либо языки (даже простые формулы Excel в массе люди не любят писать). Поэтому в 99% случаев языка нет - есть диалоги настройки логики - выбрать, ткнуть итд. Т.е. мы вообще ориентируемся на то, что даже интерфейс дизайнера процессов не командно-языковый, а визуальный, но без сложных диаграм. Да, сайт у них очень специфичный подачей. Ну постараюсь вникать.

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

Программы партии – это «простые» довольно вещи. Они должны быть простыми для понимания большинством народа (на сам деле, программы читают единицы – в основном это конкуренты 8-), до голов избирателей доносятся лишь месседжи по мотивам программ). Причем эти «понимания» могут быть (это заложено в программу) совершенно разными у разных больших групп населения. Часто, даже прямо противоположными по смыслам, но обычно это оттенки. Главное – эти смыслы должны быть положительными, но обязательно должна быть борьба против чего-то и/или за светлые идеалы. В этом парадокс и фишка «партийных программ». Для них важна реализация, точнее, партийная программа это средство, а цель – голоса избирателей. В одном и том же «тексте» программы надо предусмотреть (упаковать заранее такую возможность) много месседжей, поэтому «правильные» программы складно и гладко обобщены. Они делаются на вырост. Вот это уже совсем не просто написать такую программу - за обманчивой видимостью простоты должны скрываться широкие возможности трактовок. «Программа партии» тоже имеет дедлайны – «моменты истины», когда избиратели голосуют либо «за» (это цель), либо «против» (это издержки реализации месседжей, спроектированных на ее основе и планируемый % промахов при стрельбе по площадям - электоральным группам). Дедлайны - сроки очередных выборов. Поэтому для реализации «партийных программ» не надо 100 супер-управленцев – они не смогут договориться. Важна управляемость, нужен работоспособный штаб из 5-10 человек – хороших специалистов. На них лежит выработка стратегии – месседжей и текстов их упаковывающих; они разрабатывают планы (это наборы сценариев, включающих аварийные и нештатные режимы) и создают работающий как часы механизм донесения месседжей до мозгов и сердец. И обязательно нужен волевой и быстро соображающий «главнокомандующий», который собирает все это в работоспособную и эффективную избирательную машину. Нужна ясно простроенная иерархия дисциплинированных исполнителей и четкая вертикаль управления, главное чтобы по пути к избирателю месседжи не искажались и доносились точно в срок. Ресурсы конечно нужны, это достаточные деньги (сумма на один голос считается с точностью до 10 центов, хотя «всегда воруют» – завышая сметы), каналы распространения месседжей - СМИ, и прямой контакт с избирателями, в том числе организация перфомансов – резонирующих на мозгах избирателей и вовлекающих их в действо. Элемент стихийности вносят действия конкурентов и «непредвиденные» действия внешних сил (включая государство, а теперь все чаще и другие государства), но в этом искусство сценарной проработки и аварийных заготовок, а также быстрота мозгов и принятия решений. Правильные «партийные программы» лучше всего реализовывать (это другая задача, отдельная от разработки) в широком инженерном подходе. Когда под задачу подбираются необходимые средства (специалисты, технологии, ресурсы). Подбираются, а не подсовываются. Вот здесь денег не надо жалеть. Главное чтобы кастинг штаба и запрос на финансовые и иные ресурсы осуществлял сам «главнокомандующий». Он знает, кто ему нужен и сколько и чего ему надо. Он главный специалист и главный отвечающий. Совершенно не допускается командовать им.

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

То что вы описываете является скорее проектом или стратегией проекта сбора % голосов на выборах, а не той "программой партии", которая, как я понимаю, описывается в посте выше.

Именно так. Я уже ответил чуть подробней.