Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Тезисы про нормы, процессы, проекты, программу и компьютерное программирование

Писать "Рассказ о..." будет vvagr, но у меня для него тезисы:

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

2. Все части организационной модели учитываются, т.е. организационная модель -- это учетная система организации (про учетные системы в применении к государству см. http://www.elrussia.ru/66836). Учет -- это сбор и хранение определённого состава данных об идентифицируемых (физических и абстрактных) лицах, объектах и/или явлениях, систематически осуществляемые определённым лицом или группой лиц. Учетность модели означает, что всегда можно найти того, кто внес в нее изменения, а сами изменения проводятся по определенным правилам (т.е. произвольное лицо не может внести изменения, а уполномоченное на ведение учета лицо не может вносить изменения произвольным образом). Учет подразумевает то, что на любой момент времени известно его состояние, и можно указать на оригинал его данных.

3. Организационная модель отчуждаема (т.е. можно передать ведение ее учета другому лицу без потерь в данных, есть способ передать состояние учета на какую-то дату "по акту"). Существует только один оригинал.

4. Все части организационной модели "модельны" -- это означает, что они отражают действительность. Это происходит двумя путями:
-- "правильность": должно быть подобие. Лучшей моделью кошки является она сама, а если это невозможно -- то другая кошка. Моделировать сетевую организацию иерархической оргструктурой может быть неправдоподобно, и следует поискать другие способы.
-- актуальность (кто-то вносит изменения в организационную модель по мере изменений в жизни организации. Если речь идет об учитываемых планах, то это означает внесение изменений в планы по мере их изменения. Если поменялись наличные запасы, то это нужно отразить -- и т.д.).
-- нормативность (обязательность, административность): внесение изменений в жизнь, которые должны отражать изменение в той части модели, которая отражает состояние "как должно быть".
То есть как модель в некоторых местах обязана прогибаться под жизнь, так и жизнь должна быть прогнута под какие-то части модели -- и мощная идея тут именно в том, что работа с организационной моделью двунаправленна: она как отражает жизнь, так и задает ее.

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

6. Методологический ход далее -- на построение понятий. Слова "норма", "процесс", "проект" понимаются как междисциплинарные понятия, наделяемые особым смыслом в рамках каких-то предметных логик. Поэтому предполагается, что связь PraxOS с другими организационными системами можно будет обсуждать в терминах этих понятий, которые будут означать немного разное в разных системах изложения, но тем не менее будут позволять налаживать хоть какое-то первичное понимание. Это значит, что слово "норма" в PraxOS будет иметь, конечно, свое особое значение -- но главные черты этого значения будут взяты из культуры (в данном случае из юридического понимания нормы, из противопоставления понятий "норма" и "патология", из понятий "культурная норма" и т.д.). Абсолютно сознательно при этом понятия вводятся не путем определения (ибо каждое определение заставляет считать понятие относящимся к той предметной области, для которой дано это определение), а путем рассказа о тех или иных способах использования понятия в разных предметах, намеренно уходя от определений. Ибо понятие -- это не высказывание, а некий конструктор, множество высказываний, из которых каждый раз подбирается наиболее подходящее по ситуации.

7. Система норм -- это часть организационной модели (т.е. система норм по определению -- учетная система). Деятельность -- управление нормами (прислеживание за тем, чтобы модель и жизнь соответствовали нашим ожиданиям). Норма -- это высказывание, состоящее из трех частей:
-- повторяющиеся времени от времени обстоятельства (состояние дел, при котором будет действовать предписание нормы).
-- повторяющееся предписание (что нужно или не нужно делать -- "процесс", или как изменить понимание обстоятельств)
-- повторяющаяся санкция (что нужно делать, если обстоятельства налицо, а предписание оказалось не выполненным).
Про разницу между диспозитивными и индивидуальными нормами еще нужно подумать.
Тем самым, к системе норм относятся:
-- внешние для организации, но обязательные к применению правовые акты государства и муниципалитетов (от правил бухучета до требований лицензирования)
-- приказы директора (об оргструктуре и т.д.)
-- приказы главного инженера/технолога (технические регламенты, правила техники безопасности и т.д.)
-- регламенты технологических процессов, "процессы" процессного подхода.
-- и прочие документы (т.е. "письменные") предписания, фиксации знаний (которые, следовательно, предполагается когда-то использовать -- т.е. подразумевается повторяемость действий по их использованию).

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

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

10. Система планирования -- это часть организационной модели, в которой учитываются планы работ. Деятельность -- управление работами (прислеживание за тем, чтобы планы и работы как-то соответствовали друг другу и жизни). Планы работ состоят из проектов, которые определяются отдельными ветвями структуры работ (но не сводятся к этим ветвям, а включают график, роспись ресурсов и т.д.). В рамках проектов могут быть использованы следующие способы определения состава работ:
-- из норм, если ожидается появление помянутых в них обстоятельств -- т.е. речь идет об использовании имеющихся знаний.
-- ad hoc, путем проектирования (design, творческого придумывания, записи необходимых "дел" или "поручений"). Если потом выяснится, что спроектированный план есть надежда повторно использовать, то это означает, что создана новая норма (абстрагированное от условий проекта знание).

11. Тем самым, процедурная часть предписания нормы, процесс -- это абстрагированный для общего случая поминаемых в норме обстоятельств проект (в случае программирования это соответствует programming by example, составлению программы путем оформления в параметризованную процедуру лога непосредственного исполнения каких-то действий). А проект -- это в значительной части своей конкретизация для данных конкретных (или ожидаемых к появлению в конкретный момент времени) обстоятельств "процессов" (что соответствует скриптингу -- указанию последовательности вызова ранее созданных объектов).
Правильно говорить "процесс строительства", "проект строительства завода номер 5", "процесс управления проектами", "проект дня 4 управления проектом 2" и т.д. Не указаны обстоятельства из нормы -- это еще норма, процесс. Если обстоятельства как-то указаны (хотя бы появилось имя, позволяющее предположить наличие конкрнетных обстоятельств) -- это проект. Неопределенный артикль -- процесс. Определенный артикль -- проект.

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

13. Основная проблема: обеспечить гибкость функционирования такой системы, ибо программа работ никогда не будет выполняться, как написано -- но и игнорировать ее наличие нельзя. На преодолении этого различия (steering -- рулем в автомобиле нельзя прицелиться, рулем движущегося автомобиля нужно вертеть) и выстроено управление: управление работами непрерывно корректирует план (программу) работ, управление нормами непрерывно корректирует нормы, управление проектами корректирует планы проекта в зависимости от того, что происходит в нормах, в планах других проектов, в жизни.

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

Даже пять Процессов управления проектами (1. инициация, 2. планирование, 3. исполнение. 4. контроль. 5. завершение) из PMBoK обычно реализуются при поставках систем управления проектами именно как набор шаблонов проектов, порождающих свой экземпляр Процесса=проект при указании, какой именно проект будет проходить по тому или иному проекту-над-проектами=конкретизированному Процессу.
Источником нормы Процесса при этом служит PMBoK, формализованное представление нормы учтено в системе управления процессами в виде шаблонов проектами. Дальше начинается путаница: правка проекта, правка шаблона проекта, правка нормы (зафиксированной в приказе по предприятию), правка в PMBoK не могут быть обсуждены в текущих понятиях: хотя бы потому, что "шаблон проекта" отсутствует в понятийной базе управления проектами (это понятие обычно вводится только на уровне программистской документации).

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

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

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

Первые попытки совместить систему нормирования и процессы в рамках одного IT-приложения, а управление проектами и планирование выпихнуть в рамки другого IT-приложения системы были мной увидены в связке ОргМастер-ТаймМастер фирмы БИГ-СПб.

Многочисленные IssueTrackers -- это попытки связать системы управления делами, планируемыми ad hoc как "проекты" с "процессами" workflow. Конечно, при этом нет никакой связи с системой нормирования.

В системах управления процессами нет никакой связи с системами управления проектами.

В системах нормирования как таковых (системах управления документооборотом) нет никакой связи ни с процессными системами (разве что сами "процессы документооборота" реализованы как workflow), ни с системами управления проектами.

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

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

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

17. Куча нерешенных проблем:
-- возможно, для каждого "управления" будет удобен свой язык: состояний для норм, процедурный (или состояний?) для планирования, объектно-ориентированный для (антропоморфизированных) ресурсов и т.д. Тут еще разбираться и разбираться, как связать все эти разные аспекты и парадигмы описания организации.
-- конечно, программирование тут рулит, ибо все ходы в нем записаны давно и последствия их уже известны. Так, если обозвать "процесс" типом, а его экземпляром "проект", то далее идет вся дискуссия про строгую и слабую типизацию. Наш выбор -- слабая типизация и сверхпозднее связывание, что дает нам надежду на гибкость (понимаемое как сознательное перемежение тактов исполнения работы и "управления нормами, управления работами/планами и т.д.").
-- обучение нормированию, планированию, ресурсному обеспечению, измерению результатов работы при этом не может быть более простым, чем обучение программированию (да еще в соответствующих парадигмах!). "Мозговые примитивы" должны быть инсталлированы в мозги, иначе ничего не получится. Поэтому-то грамотных планировщиков проектов мало, грамотных нормировщиков мало, грамотных операционных менеджеров мало.
-- все это не снимает необходимости управлять людьми (руководства: умение уболтать людей следовать нормам, выполнять план, добиваться измеримых целей и т.д.), не снимает необходимости грамотно ставить цели. "Все это" -- моделирование организации, конечно. Структуру модели нужно знать, языки моделирования нужно знать. А уж плохая или хорошая модель будет сделана по этой структуре и на этих языках -- предмет совсем других тезисов.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 8 comments