Возвращаясь к идее симултрека (информационной системе обеспечения деятельности, которая состоит из моделей различных аспектов организации, плюс обеспечения дистантного доступа членов организации к этим моделям. Тем самым люди организуют свою работу вокруг такой системы примерно так же, как толпы людей в аэропорту организуются вокруг табло прилетов-отлетов).
В центре всего стоит та самая JIRA (http://www.atlassian.com/software/jira/) или скажите мне, что круче и лучше для данного случая). Она обеспечивает tasks и всю механику группировок и комментов вокруг них, а также инфраструктурные сервисы -- почту и т.д.. Главная цель -- обеспечить развертку событий-операций-комментов во времени, хронологическую ленту происходящего. JIRA отвечает за модель действий в деятельности.
Рядом с JIRA должна быть Confluence: вики-ресурс (http://www.atlassian.com/software/confluence/), обеспечивающий работу со знаниевыми моделями -- текстами. И презентациями (на эту тему отдельный плагин Gliffy, типа вики-Visio -- http://www.gliffy.com/products/confluencePlugin/).
В принципе, все дальнейшие модели можно подключать помощи JIRA extentions (http://confluence.atlassian.com/display/JIRAEXT/Home) -- разнообразных плагинов.
Прежде всего это должен быть движок учета ресурсов и вычисление критического ресурсного пути (голдратовское управление проектами). Совершенно непонятно, как программно-исследователькую специфику потока дел JIRA упаковать в рамки ресурсно-временных ограничений, но как минимум, соответствующую софтверную механику вполне можно навесить. Я когда-то написал проектный движок, фиксирующий WBS (work breakdown structure) и поиск критического пути, используя средства программирования DATATRIEVE (http://en.wikipedia.org/wiki/Datatrieve) на CM-4. Отсюда вывод, что на скриптовом языке JIRA такие алгоритмы написать совсем просто (и еще вдобавок неожиданное для меня открытие, что проектным управлением я занимаюсь уже больше двадцати лет: на DATATRIEVE я искал критический путь году эдак в 1985).
Я пока не понимаю, что может быть инструментом, обеспечивающим работу с финансовыми моделями (througput accounting http://en.wikipedia.org/wiki/Throughput_accounting, я не имею ввиду налоговую бухгалтерию, для которой инструментом вполне может быть 1С). Похоже, весь управленческий учет просто пишется на скриптовом языке JIRA и с использованием тамошней базы данных.
Организационные модели можно учесть, добавив к получающейся дьявольской программной смеси свободный ГосМастер (итог работ "Электронной России" 2006г., еще не выложены. Результаты работ 2005г. тут: http://www.elrussia.ru/orgmodel). Проблема в том, что управленческий стиль, предполагающий организационное моделирование "общего вида" и стиль моделирования деятельности в JIRA+плагины -- это про совершенно разное и для коллективов совершенно разного размера. Поэтому тут нужно несколько раз подумать, перед тем как склеивать одно с другим.
По идее на все это нужно навесить какую-нибудь приличную систему управления версиями на модели -- скажем, Perforce (http://www.perforce.com/). Но и тут засада: Perforce вполне совместима с JIRA (есть соответствующая разработка), но только в задаче управления версиями программного продукта, когда задачи JIRA относятся к вносимым изменениям в программный код. А вот когда у вас плывет версия какого-нибудь нормативного акта, связанных с ним презентаций и поясниловок, или плывет техзадание на строительство линии электропередачи так, что у вас меняется и состав работ, и заказываемые материалы и оборудование, и подготовленная рабочая документация, то Perforce тут мало помогает. Но сама идея версий и их ветвлений в проектном управлении и моделировании представляется крайне интересной. Можно ли запустить Perforce прямо над страничками Confluence -- вот в чем вопрос!
Ну, и ко всему этому прибавляются системы прикладного моделирования и сценирования, исходные данные для которых и результаты работы с которыми тоже правильно было бы как-то учитывать.
Эффект присутствия может обеспечиваться Second Life (www.secondlife.com) и голосовым чатом (http://www.goteamspeak.com/), c полным пониманием, что результаты быстрых обсуждений голосом затем должны быть учтены -- ну ровно как после телефонного обсуждения, или после очного совещания.
Соответствующие этому программному месиву теоретические модели из области организации деятельности -- agile product lifecycle management и прочие agile-методы (см., например, девятистрочный http://agilemanifesto.org/ для примера подобного подхода в области софтостроения), которые нужно как-то совместить с методами организации работ больших коллективов (то есть ровно не-agile: процессы, проекты, контракты, планы). Тут очень даже есть над чем подумать: как в одной упряжке удержать коня-тяжеловоза и трепетную скоростную лань. Понятно, что для 15-150 человек трепетной лани вполне достаточно, но вот если эти 150 человек управляют еще 6000 (а последние наши клиенты были ровно такие), то тут приходится и про тяжеловозов думать.
Это, конечно, все довольно сырые размышления. Но мне интересно было бы в 2007г. попробовать сделать пару-тройку практических шагов в заявленном направлении.