Основные стейкхолдеры разрабатываемого организационного решения и их интересы:
1. Организатор (менеджер)
-- привлекает к выработке организационного решения всех конкретных стейкхолдеров организации
-- утверждает организационное решение, оформленное в виде организационной документации
-- убеждается сам, и убеждает других в необходимости принятия решения
-- защищает решение от критики еще более высокого руководства
-- проверяет (оценивает), насколько удался проект уже после его окончания
2. Инженер
-- приспосабливает технические процессы к организационным реалиям
-- обеспечивает связность и выполнимость технических процессов
3. Специалист по информационным технологиям
-- готовит информационную инфраструктуру к поддержке организационного решения
-- обеспечивает наличие формальных описаний организационного решения
4. Бизнес-аналитик
-- приспосабливает организационные процессы обеспечения проектов и проектные процессы к техническим реалиям
-- обеспечивает связность и выполнимость организационных процессов обеспечения проектов и проектных процессов
5. Разработчик PraxOS
-- разрабатывают принципиальное организационное решение
-- консультируют адаптацию организационного решения в конкретной организации
Требования к описаниям PraxOS:
1. Все тексты должны быть русскоязычными. Ссылки на англоязычные стандарты возможны, но все необходимое содержание должно быть доступно на русском языке.
2. Тексты по возможности должны быть изложены в терминологии, понятной большинству стейкхолдеров, прежде всего инженерам (так, нельзя ожидать, что инженеры хорошо ориентируются в айтишном сленге типа "воркфлоу", "IDEF0-диаграммы" и т.д.).
3. Предлагаемое решение должно учитывать интересы всех стейкхолдеров (уже на уровне разработки организационного решения должно быть понятно, в какой форме привлекать разных людей). Более того, подразумевается, что организационное решение позволит различным стейколдерам быстрее договариваться (оно предлагает "язык").
4. Решение должно быть "мейнстримным" ("модным"), для этого оно должно опираться на (или еще лучше -- совпадать с) международными стандартами, чтобы избавить менеджеров от лишних доказательств своих выборов вышестоящему начальству и партнерам. Должны быть обеспечены "доказательные материалы" уместности решения и используемости стандартов (это очень похоже на википедийный запрет ориссов).
5. Общий "язык" решения, на котором будут договариваться разные специалисты организации, не должен быть "изобретенным". Он должен опираться на международные стандарты.
6. Описание решения должно максимально формализовываться, ибо неизбежна его поддержка со стороны информационных технологий.
7. Решение должно быть изложено в форме разработанной в организации ("родной", а не "заимствованной") распорядительной документации с понятной процедурой коллективной разработки, согласования и утверждения.
8. Должна быть показана возможность проверки, насколько удался предлагаемый оргпроект после его окончания (пригодность к оценке).
9. Должны быть обеспечены учебные материалы по предлагаемому решению (примеры, задачи, методические рекомендации, курсы и т.д.).
10. Должно быть программное обеспечение по предлагаемому решению.
11. Решение должно быть широко доступно для сотрудников использующей его организации, независимо от существующей там системы распространения знаний.
Архитектурное решение подхода PraxOS:
На базе анализа содержимого международных стандартов и лучшего управленческого опыта разрабатываются описания трех типов:
1. Русскоязычный понятийный минимум в виде повествовательного текста, вводящего понятия. Понятийный минимум сопровождается Глоссарием, в котором дается обоснование перевода. Понятийный минимум разрабатывается на базе не столько одного стандарта, но как минимум на базе нескольких стандартов, при этом используется подход PraxOS http://ailev.livejournal.com/640702.html. Это позволяет получить хорошо формализуемые русскоязычные описания предметных областей, в которых не используется узкоспециальная лексика.
2. Требования к воплощающему оргрешение процессному стандарту организации, выраженные в терминах понятийного минимума. Форма стандарта организации позволяет привлечь к разработке всех конкретных стейкхолдеров данной организации. Процессность стандарта позволяет предложить конкретные процедуры оценки. Это суть решения: "инструкция-1 по разработке инструкции-2", при этом инструкция-1 общая для всех, а инструкция-2 уже адаптирована к условиям конкретной организации.
3. Описанный в Требованиях организационный процессный стандарт должен учитывать особенности организации и должен быть сформулирован на архитектурном уровне абстракции (чтобы потом можно было в рабочем порядке в выполнимых описаниях, принимаемых в форме самых распорядительных документов, учесть организационную инфраструктуру, используемые методы работы, учесть обученность персонала).
4. Состав Требований к Концепциям делается на основании списка процессов ISO 15288:2008 и предлагает конкретизацию методов реализации практик системной инженерии интеграцией этих тщательно выбранных из свалки организационных мод и поветрий методов с опорными описаниями 25 процессов системной инженерии из ISO 15288 посредством все того же подохда PraxOS http://ailev.livejournal.com/640702.html.
5. Разработанные материалы открыто публикуются в Интернете и доступны для скачивания всем потенциальным стейкхолдерам оргпроекта.
Пример реализации подхода PraxOS: документы "Подход системной инженерии к управлению жизненным циклом" и "Требования к Концепции жизненного цикла" из http://ailev.livejournal.com/638740.html (это самое начало выполнения требований, многого еще не хватает. Так, "обоснование необходимости", "указания на софт" и многое другое пока есть только в подстрочниках семинаров http://www.slideshare.net/ailev/slideshows, а многого требуемого так и вообще еще нет).
И абсолютно понятно, в какую сторону двигаться, чтобы реализация двигалась в сторону более полного удовлетворения требований: включить обоснования необходимости использования предлагаемых методов работы внутрь текстов, формально моделировать описания решений, сделать много больше учебных материалов (в особенности -- примеров), указать имеющийся уже софт и т.д..