Методология

Благо дарю за ответ!

Тут вопрос именно методологии. Прежде всего, насчет документов. По системному подходу документы должны быть «атомизированы». То есть краткие и ограниченные. По моему опыту — не более 3-5 страниц (в эквиваленте А4). Принцип «гипертекстового знания». Пример про цели. Описание целей внедрения в Карте проекта — 2-3 предложения максимум. 

Нюанс системного подхода: цель всегда указана для конкретного пользователя, только с его точки зрения, только в одном аспекте. Целей может быть 5-9. С разных точек зрения (аспект по ISO 81346).

А теперь самое сложное, потому, что совсем иная логика в системном (холистическом) подходе: 

1. Одно описание цели всегда неполное, неточное, противоречивое иным целям. Даже не стремимся к уточнению!

2. Только все вместе цели дают приемлемое описание цели создания системы. Принцип аддитивной логики. Аналогия: 10 мудрецов описывают слона на ощупь в темной комнате. 

3. Иерархия целей всегда многомерная. В разных аспектах — своя иерархия. Аналогия: обычно, иерархия целей строится в плоскости. А тут — многомерная структура, в объеме. Поэтому в одной системе координат одна цель — часть другой. А в иной системе координат — одна из целей вообще не существует. Целостное представление дает только суммарная, многомерная картинка.

4. Цели сформулируйте в виде существительных. Отдельно — в виде глаголов. Существительное — объект. Глагол — процесс. Никогда не совмещайте оба варианта.

5. Формулировка изначально не для понимания человеком. Изначально и всегда ориентируемся на информационную систему.

6. Более корректно принципы формулировки целей описаны в методологии LFA (Логико-структурный подход). И еще в НЛП, ищите «правила хорошо сформулированной цели».

Как бы Вы не сформулировали цели — всегда описание целей будет неполным, противоречивым и неточным! Но это не мешает работать и делать проект.

Принцип методологии реального проекта — как использовать постоянные изменения для работы проекта. Поэтому все документы проекта всегда меняются. 

Кстати именно поэтому они и делаются короткими и всегда есть main document по ISO 11005 для определенной части проекта. Обычно — для каждого объекта есть такой документ. Обычно в виде списка документов, которые связаны с этим объектом.

Получаем для каждого элемента проекта есть только один документ. А в нем — список связанных документов. Не приложения к документу! А именно все отдельно. 

Пример. 

Классический подход: документ требования к системе (Д1). Один документ, в начале — оглавление. К нему 10 приложений со схемами или таблицами. 30-50 страниц

Системный подход: требования к системе — главный документ. В нем только типа «оглавление» из Д1 со ссылками на остальные документы. Отдельно — функциональные требования. Это документ Д2. На него есть ссылка в Д1. Но он СОВЕРШЕННО отдельный и независимый документ. Нефункциональные требования — документ Д3. Все то же самое. И так для КАЖДОГО документа, включая все бывшие приложения. Все эти документы связаны по метаинформации в репозитории документов проекта. Для чего так: Заказчику надо показать требования для экономистов. Это отдельный документ. Бери и работай. На остальные требования — не влияет. Для технологов — свой документ. И так для каждого заинтересованного лица. Свой взгляд, своя точка зрения. Свой аспект. И только все вместе — дают полный комплект требований к системе.А насколько проще все согласовать… Не надо переделывать все ТЗ. Очень просто разграничить доступ. Ну и так далее. Это не я все придумал! Я только вольно, криво и косо пересказал одну часть стандарта ISO по технической документации.

Могу дать доступ до своей электронной библиотеки, там все это есть более подробно и со стандартами. Библиотека на G suite организована, поэтому пришлите свой адрес на Гугл аккаунте gmail, и я тогда дам доступ к сайту. Доступ всегда бесплатный, но ограничен, потому, что там куча стандартов. А они типа не open source… Опаньки… Мой адрес vb@in-genium.in.

В заключение, немного целей системы ERP. Аспекты по ISO 81346, основные (= и -), дополнительные (финансовый #F и номер проекта #P для нумерации ).

Аспект функции (=):

Цели:

=F.001 Долгосрочный план. Показатель достижения цели (параметр): логический (да/нет)

=F.002 Краткосрочный план.Показатель достижения цели: логический (да/нет)

=F.003 План продукции. Показатель достижения цели: логический (да/нет)

Аспект финансовый (#F).

Цели:

#F.001 Транзакция продажи. Параметр: продолжительность. Значение: 0,1 нормочаса.

#F.002 Транзакция продажи. Параметр: затраты на осуществление. Значение: 100 рублей.

#F.003 Транзакция продажи. Параметр: количество за 1 месяц. Значение: 20 000

#F.004 Транзакция продажи. Сложность. Значение: низкая. Тип: выбор из списка «низкая» «средняя» " высокая". Метод оценки: СТО #P396=AF&BPQ001. Код документа я использовал реальный, на основе ISO 61355.

#F.005 Административные затраты. Параметр: сумма за 1 месяц. Значение: -20% Метод оценки: СТО #P396=AF&BPQ002.

Аспект продуктовый (продукт — сама система ERP).(-)

-P.001 Количество лицензий. Параметр: количество. Значение: 10

Все, надоело писать цели. Реально интеграция системы ERP по стандарту IEC 62264 может быть на 7 уровнях. Что-то типа как в модели OSI для инета. Все уровни прописаны, что где, как и когда происходит. Например,

Level 4 defines the business-related activities needed to manage a manufacturing organization. 

Manufacturing-related activities include establishing the basic plant schedule (such as material use, delivery and shipping), determining inventory levels and making sure that materials are delivered on time to the right place for production.

То есть документ: #P396=AF.004&BEC001 Цели внедрения ERP будет содержать цели только для шефов отделов. И там не будет целей для уровня 5.

А для владельцев фирмы будут цели, структурированные и описанные для уровня 5. Что на этом уровне — тоже все прописано в стандарте. Получается, что в идеале будут 6-7 документов о целях внедрения системы ERP. Каждый получит только специалист с определенного уровня. И каждый документ описывает ВСЕ цели внедрения системы. Но только с точки зрения того, кому он адресован (соответствует номеру уровня) и не содержит ненужных деталей. ЦЕЛОСТЬ системы целей увидеть невозможно, и такая задача даже не ставится. То есть никакой «декомпозиции» целей, никакой «полноты, непротиворечивости» и т. п. нет и даже такая задача для ПРОЕКТА В ЦЕЛОСТИ не ставится. 

Да, есть иерархия целей, да, может быть их «декомпозиция» — но только в каком-то одном аспекте. Один аспект — один документ. 

Ага, и документ — это не «бумажка». А просто «обособленная часть информации». Документы для 5-6 уровня будут очень короткими. В идеале — 5-6 уровень это один абзац. Шефы это любят. А на уровне 1 — сотни, если не тысячи документов, по одному на каждый процесс.

Как все это организовать, соединять, следить? Несложно, это все тоже описано в тех же стандартах ISO IEC. По промышленным проектам — все реализовано в ePlan.

Для всего остального хватает G Suite. С технической точки зрения, для составления полной технической документации для строительства небольшого завода нужно немного времени, если применять новые методы системного подхода. Вся документация для такого проекта, вплоть до детальных списков с ценами всех элементов (до шурупа…), со всеми схемами для исполнителей, на 3 языках, делается за 1-2 дня. Если уже есть готовая библиотека типовых элементов! 

Что касается проектов ИТ, или научных проектов, то все проще.

Например, мы вдвоем ведем одновременно сейчас 6 проектов:

Производство чистящих средств.

Производство краски.

Переработка промышленных отходов.

Функциональные продукты из пророщенного зерна.

Моделирование жилищного кооператива (фонда?)

Развитие сети MLM

Ну и успеваем делать методологию для ведения таких проектов. Это типа еще целый проект.

Это не потому, что мы типа крутые… Это просто такая методология, такой инструмент. Мы пока владеем им довольно посредственно. Да, с 2008 года мир сильно изменился. И да, я сам офигевал, когда читал книги по UML RUP PM и совершенно ничего не мог понять. Полная ахинея и заумь. А реально — совсем иной подход, холистический, целостный. И очень простой. Расширение классического подхода на иной логике и иной методологии. 

И, кстати, про институты и про обучения. Когда я понял, что половину жизни потратил на изучение старых, кривых и косых методов — то немного разозлился на себя и на учителей. А теперь, вижу, что ни в России, ни тут в Польше ничего в обучении не поменялось. И учат точно такому же отстою. Все те же методы на основе редукционизма, нет обучения на основе системного (холистического) подхода. И тогда мне стало совсем фигово: вся эта кодла инженеров, ученых, манагаров, программастов после институтов годны только как кассиры в магазин. Приходится ПОЛНОСТЬЮ переучивать. И 50% времени — это выбивание их головы того мусора, что туда заложили в институтах. Реально — специалисты очень востребованы. Бабла платят кучу, работа — интересная. Но просто люди не понимают друг друга. Разная логика на уровне архетипов и самих основ сознания! Прикол: у некоторых людей перестройка логики при смене подходов на холистический приводит иногда просто к потере сознания. Отключка на 2-3 минуты и полная амнезия ближайших 5-10 минут разговора. 

Так что все совсем не так, как мы думали… Все гораздо ЛУЧШЕ!