Внутренний и внешний консалтинг - что лучше?

[Елена Сысовская]

И все-таки, цели внутреннего и внешнего консалтинга разные.
Ситуация. На то, чтобы написать ТЗ на внутреннем проекту ушла как миминум неделя, да еще недели три проработки и настройки. Никто из функциональных специалистов (скорее всего) этот документ читать не будет. В лучшем случае пройдутся по списку операций и отчетов. И спросят руководитя проекта, уверен ли он в том, что ТЗ действительно отражает решение их проблем. Потому что предполагают, что за месяц разработки решения их проблемы изучили и будут решать. Единственная потенциальная полезность от этого документа (кроме систематизации знаний о решении, но это- внутреняя цель проектной группы и элемент культуры ее работы). - вдруг его отдадут на внешний аудит (и заплатят за него годовую зарплату проектной группы ). Это при том, что документ этой написан внутренней службой.
ТЗ необходимо на проекте, который ведут внешние консультанты, потому что по детально описывает - что и как консультанты собираются делать дальше и какие задачи они собираются решать в рамках проекта, и какие ограничения заложены в решение. После этого, если документ подписан, риски за то, что делается "не то и не так" переходят на сторону клиента. Оценить, насколько ТЗ решает проблемы заказчика, самому заказчику очень сложно - документ написан в терминах будущего решения и проектных работ, и заказчик ими не владеет настолько, чтобы представить себе, как все это будет работать. Тем более, что контрольный пример к этому времени обычно не представлен - для этого же надо проделать часть работ по настройке, а это обычно не входит в рамки этапа по разработке ТЗ. Но сейчас не о рисках, об этом уже говорили.
Если ТЗ пишет внутрення проектная группа, то цели этого документа совершенно другие. Внутренней группе не удастся сказать потом "этого в ТЗ не было", и ТЗ становится документом, который нужен самой группе как история развития постановки задачи, а постановка однозначно развиваться будет - о том, что ТЗ подлежит развитию в ходе всего проекта, тоже уже говорили. Гарантом качества решения и его соотвествия задаче становится внутрениий специалист - руководитель проекта, а не формальный документ. Как прийти к общему общее пониманию задачи между проектной группой и функциональными специалистами - он должен решить сам. Но есть стандартные способы, эффективные или нет - они часть стандартной методологии, и для внешней оценки хода проекта ТЗ все-таки приходится писать, хотя это и побочный продукт деятельности группы внедрения. Что такое тщательная проработка документов, действующих в рамках сомнительных методик и высокорисковых проектов?
Это неэффективное по факту ТЗ пишут на каждом проекте заново. Фактически не происходит накопления и использование опыта. Не смотря на то, что консультантов нанимают именно потому, что у них есть опыт готовых решений в похожей области, они начинают все сначала на каждом проекте ( и за средства заказчика, кстати). "Я в сотый раз опять начну сначала...". Можно конечно сказать, что консультантам выгодно каждый раз брать деньги за изучение принципов работы стиральной машинки перед тем, как взять деньги за стирку. С точки зрения клиента, разработка ТЗ - это - потеря денег и времени, потому что никакое внедрение при этом не происходит.
Так вот о ТЗ, "изобретениях велосипедов", накоплении опыта и открытости знаний.
На нашем проекте есть разработанное ТЗ, которое по сути - техрешение, только не разработаны отчеты и процедуры загрузк - выгрузки, выполнена первичная настройка системы, сделан контрольный пример - результат месяца работы нашей команды. Так как на данный момент мы не внешние консультанты, и не продаем ТЗ клиентам, его содержание и форма не являются предметом какой-либо тайны, а сам документ является просто побочным продуктом проекта. Команда внутренних разработчиков ни с кем не конкурирует в части разработки ТЗ, потому что организация продает совершенно другие товары и услуги. В ТЗ не раскрывается структура организации и информация о ее коммерческой деятельности, поэтому его внешние обсуждение безопасно с точки зрения корпоративной безопасности.
Это не значит, что мы собираемся публиковать проектные документы в открытом доступе для всех. Мы говорим о том, что внутренние команды с проектов, которые занимаются разработкой решений по похожим задачам, могли бы объединить свои знания и наработки, и даже выполнять часть работ совместно. Я думаю, менеджерам внутренних проектов, в отличии от внешних консультантов, не в чем конкурировать, а можно открыто обсуждать свои проекты и делится опытом. Для организации, имеющей распреденную в пространстве структуру, центр консолидации данных, занимающейся торгово - закупочно - производственной деятельность, разработанное на нашем проекте ТЗ было бы применимо процентов на 80, как минимум - и мы могли бы поделится своим опытом и наработками, если бы встретили команду, готовую так же быть открытой и вести совместно часть задач. Например, по разрабоке финансовых отчетов, которые почти у всех имеют стандартные статьи, или написанию выгрузки в 1С данных для бухгалтерии, по проработке классификаторов материальной номенклатуры, проработке задач по бюджетированию - это все достаточно стандартные процедуры, и реализация из от проекта к проекту будет отличаться не сильно. Такое сотрудничество могло бы включать накопление библиотеки программ (имеются в виду кастомизации под Аксапта и внешние программы), или накопление решений и "историй болезни" проектов, существенно расширяя круг специалистов, с которыми можно посоветоваться по той или иной проблеме, имеющих опыт решения каких-либо задач, проработать совместно вопрос.
У нас есть проект ресурса, на котором могло бы происходить такое взаимодействие, базирующийся на терминальном доступе к работающей системе с тестовыми настройками и данными - с ограниченным доступом к серверу, разумеется, только для участвующих в работе проектных команд. При этом мы считаем, что потери от закрытости в данным случае существенно выше, чем потери от того, что кто-то прокрался к "источнику знаний" под чужим логином.
Ведь у внутрениих исполнителей нет цели каждый раз все переделывать заново и брать за это деньги, обучая новых менеджеров и консультантов - так, может быть, объединить свои усилия по разработке решения в похожей функциональной области?
Если есть внутренние команды, самостоятельно ведущие проеты внедрения, заинтересованные в таком сотрудничестве - пишите, it2b@narod.ru