Системы поддержки коллективной работы против систем поддержки оформления результатов работ
Увы, современные информационные технологии зачастую поддерживают не суть дела, а только форму дела. Форма дела обычно заключается в том, что принятое каким-то чудом в результате сущностной содержательной работы решение, уже изложенное по всей форме, проходит цепочку согласований и утверждений. Согласования и утверждения видимы для информационной системы и менеджеров, а содержательный ход дела -- невидим. Даже инженеры, когда дело доходит до айтишных систем, теряют свой инженерный нюх и обсуждают только административные аспекты -- утверждения уже известного, изменения уже понятного и т.д.. Именно на этой подмене сути дела формой дела и процветают системы процессного управления с их длиннющими цепочками последовательностей операций (каждая из которых обозначает не столько саму сложную работу, сколько факт утверждения полученных результатов этой работы). Если задумываться, что как поддержать содержательную работу, а не утверждение ее результатов, то неизбежно приходишь к необходимости ввести понятие кейса (а не документа), изменить границы кейса (момент открытия кейса оказывается гораздо раньше, чем момент начала согласования), и поддержать коллективную работу над кейсами не системой документооборота (а хоть и инженерного документооборота), а системой класса adaptive case management -- в которой многие действия можно проводить не согласно заранее спланированным регламентам, а по мере возникающей содержательной необходимости.
Вот только несколько примеров из моей практики:
1. Обычно правление крупных компаний разделяется примерно поровну, когда я задаю ключевой вопрос по выбору системы документооборота: вам нужно, чтобы всегда формально знать, кто виноват -- или вам нужно обеспечить продуктивную работу? В первом случае вам нужна именно система документооборота, и она автоматически попадает в ведение канцелярии, которая драконовски нагибает всех на выполнение ГОСТов делопроизводства. Во втором случае вам нужно ставить issue tracker (самая распространенная форма groupware для промышленной коллаборации -- предыдущее поколение адаптивного управления кейсами). В первом случае у вас всё будет юридически корректно задокументировано, и соблюдены все регламенты. Во втором случае работа будет идти не столько по регламентам (хотя и это возможно), сколько по уму -- ибо отнюдь не вся работа умещается в регламенты.
Обращу особое внимание, что даже не все знают про использование issue trackers как систем управления процессами -- а ведь они не только могут выполнять пересылки и уведомления, определенные в design time, но и делать то же самое в runtime (да еще и хитрыми способами -- не только push, но и подписками/pull). Новые поколения issue trackers интегрируются с wiki, системами управления конфигурацией/ведения версий (в случае САПР такое объединение называется PLM-системой), системами проектного управления и учета времени и т.д.. Но это не канцелярский документооборот, которого не интересует содержательное решение вопроса (и тем самым привлечение к issue/case самых разных людей, итерации, эксперименты, дополнительные совещания и прочее, что не отражено ни в одном регламенте), а интересуют только предписанные в design time визы.
2. Управление инженерными изменениями часто умудряются переформулировать из работы с кейсом в работу с визированием уже готовых решений. Процессное управление и инженерный документооборот поддерживают в случае управления изменениями только запросы на изменения. Но это ведь только вершина айсберга! Сама подводная часть -- это откуда взялся запрос на изменения! А ведь там много исследовательской работы, уточняющих причины и необходимость изменения, много проектной работы, ибо изменение нужно спроектировать -- и только затем можно начинать согласование по утверждению (каковое согласование тоже сопровождается содержательной работой, невидимой глазу).
Системы управления жизненным циклом можно рассматривать двояко: как системы, позволяющие отследить инженерную коллизию, и далее поддерживать работу с ней вплоть до формулирования снимающего коллизию инженерного решения и последующего утверждения этого решения в составе инженерного базиса (baseline) -- или просто как системы, которые формально проводят заранее предписанные ГОСТами согласования. Разница тонкая, ибо в какой-то момент инженеры начинают думать не в терминах своих инженерных систем, а в терминах подписываемых ими бумаг -- далее весь содержательный разговор и все содержательные обмены информацией происходят абсолютно неподдержанные софтом ("на коленке"), ибо софт в силу самой постановки задачи поддерживает только подписание бумаг.
3. Обсуждение ППР (плана производства работ) сооружения, получаемого по технологии Multi-D на последнем заседании Русского отделения INCOSE (http://incose-ru.livejournal.com/31246.html). Как и в предыдущих случаях, столкнулись два разных рассмотрения: административно-бюрократически речь идет о разработке ППР как документа со многими подписями, а потом внесение в этот ППР четко согласованных изменений (полагающихся готовыми к тому моменту, когда их начнут согласовывать). Но ведь есть и содержательное инженерное рассмотрение, при которой ППР сначала разрабатывается, а потом непрерывно приводится в соответствие с жизнью. Эти два взгляда вполне совместимы, если непрерывно актуализируемая модель производства работ время от времени выплёвывает бюрократам выписки, которые они затем утверждают в полном соответствии с их старинными бюрократическими правилами бумажной работы. Бюрократов ведь не волнует, из какого сора получаются те документы, которые они потом согласуют -- а инженеров как раз интересует поддержка способа, которым они эти документы для согласования производят. Ибо нет способа -- нечего оказывается и согласовывать. Ужас в том, что ход получения начального согласовываемого документа в знаниевой работе чрезвычайно похож на согласование и редактирование в ходе согласования -- но айтишники не поддерживают общение инженеров, они поддерживают только общение инженеров с начальниками.
Недаром одной из причин сохранения "бумаги" называют трудности в определении того, "кто будет сидеть" за допущенные при актуализации модели ошибки. С другой стороны, сама работа по актуализации модели и выработке тех самых "изменений к ППР" вообще не попадает в рассмотрение, для нее не рассматриваются "процессы" (ведь там не столько привычные "согласования", сколько просто содержательная и довольно разнообразная работа, плохо поддающаяся "процессному подходу" в его классическом варианте) и коллаборация в этой работе фактически не будет поддержана ничем, кроме электронной почты.
Вот только несколько примеров из моей практики:
1. Обычно правление крупных компаний разделяется примерно поровну, когда я задаю ключевой вопрос по выбору системы документооборота: вам нужно, чтобы всегда формально знать, кто виноват -- или вам нужно обеспечить продуктивную работу? В первом случае вам нужна именно система документооборота, и она автоматически попадает в ведение канцелярии, которая драконовски нагибает всех на выполнение ГОСТов делопроизводства. Во втором случае вам нужно ставить issue tracker (самая распространенная форма groupware для промышленной коллаборации -- предыдущее поколение адаптивного управления кейсами). В первом случае у вас всё будет юридически корректно задокументировано, и соблюдены все регламенты. Во втором случае работа будет идти не столько по регламентам (хотя и это возможно), сколько по уму -- ибо отнюдь не вся работа умещается в регламенты.
Обращу особое внимание, что даже не все знают про использование issue trackers как систем управления процессами -- а ведь они не только могут выполнять пересылки и уведомления, определенные в design time, но и делать то же самое в runtime (да еще и хитрыми способами -- не только push, но и подписками/pull). Новые поколения issue trackers интегрируются с wiki, системами управления конфигурацией/ведения версий (в случае САПР такое объединение называется PLM-системой), системами проектного управления и учета времени и т.д.. Но это не канцелярский документооборот, которого не интересует содержательное решение вопроса (и тем самым привлечение к issue/case самых разных людей, итерации, эксперименты, дополнительные совещания и прочее, что не отражено ни в одном регламенте), а интересуют только предписанные в design time визы.
2. Управление инженерными изменениями часто умудряются переформулировать из работы с кейсом в работу с визированием уже готовых решений. Процессное управление и инженерный документооборот поддерживают в случае управления изменениями только запросы на изменения. Но это ведь только вершина айсберга! Сама подводная часть -- это откуда взялся запрос на изменения! А ведь там много исследовательской работы, уточняющих причины и необходимость изменения, много проектной работы, ибо изменение нужно спроектировать -- и только затем можно начинать согласование по утверждению (каковое согласование тоже сопровождается содержательной работой, невидимой глазу).
Системы управления жизненным циклом можно рассматривать двояко: как системы, позволяющие отследить инженерную коллизию, и далее поддерживать работу с ней вплоть до формулирования снимающего коллизию инженерного решения и последующего утверждения этого решения в составе инженерного базиса (baseline) -- или просто как системы, которые формально проводят заранее предписанные ГОСТами согласования. Разница тонкая, ибо в какой-то момент инженеры начинают думать не в терминах своих инженерных систем, а в терминах подписываемых ими бумаг -- далее весь содержательный разговор и все содержательные обмены информацией происходят абсолютно неподдержанные софтом ("на коленке"), ибо софт в силу самой постановки задачи поддерживает только подписание бумаг.
3. Обсуждение ППР (плана производства работ) сооружения, получаемого по технологии Multi-D на последнем заседании Русского отделения INCOSE (http://incose-ru.livejournal.com/31246.html). Как и в предыдущих случаях, столкнулись два разных рассмотрения: административно-бюрократически речь идет о разработке ППР как документа со многими подписями, а потом внесение в этот ППР четко согласованных изменений (полагающихся готовыми к тому моменту, когда их начнут согласовывать). Но ведь есть и содержательное инженерное рассмотрение, при которой ППР сначала разрабатывается, а потом непрерывно приводится в соответствие с жизнью. Эти два взгляда вполне совместимы, если непрерывно актуализируемая модель производства работ время от времени выплёвывает бюрократам выписки, которые они затем утверждают в полном соответствии с их старинными бюрократическими правилами бумажной работы. Бюрократов ведь не волнует, из какого сора получаются те документы, которые они потом согласуют -- а инженеров как раз интересует поддержка способа, которым они эти документы для согласования производят. Ибо нет способа -- нечего оказывается и согласовывать. Ужас в том, что ход получения начального согласовываемого документа в знаниевой работе чрезвычайно похож на согласование и редактирование в ходе согласования -- но айтишники не поддерживают общение инженеров, они поддерживают только общение инженеров с начальниками.
Недаром одной из причин сохранения "бумаги" называют трудности в определении того, "кто будет сидеть" за допущенные при актуализации модели ошибки. С другой стороны, сама работа по актуализации модели и выработке тех самых "изменений к ППР" вообще не попадает в рассмотрение, для нее не рассматриваются "процессы" (ведь там не столько привычные "согласования", сколько просто содержательная и довольно разнообразная работа, плохо поддающаяся "процессному подходу" в его классическом варианте) и коллаборация в этой работе фактически не будет поддержана ничем, кроме электронной почты.