На грани провала
Ни для кого не секрет, что достаточно много проектов по внедрению программных продуктов заканчиваются провалом. Секрет в том, каковы причины этого провала. Какая фирма, руководитель или программист публично признаются в этом? Данная публикация не претендует на всеобъемлющий анализ, и основана только на личном опыте автора. А так как мне приходилось выступать и со стороны Заказчика, и со стороны Исполнителя, надеюсь избежать односторонней оценки событий.
Серый откат
Оплата «в конверте» ключевым сотрудникам Заказчика, от которых зависит заключение договора и последующее его продолжение, настолько распространено, что чувствуешь себя «белой вороной», стараясь выстроить договор без отката.
Случай из практики. Однажды мне довелось выступать экспертом со стороны Заказчика при внедрении отраслевого программного продукта на базе «1С:Предприятие 8» фирмой-разработчиком. Заказчиком выступало достаточно крупное предприятие, которое могло себе позволить и доработку тиражного продукта «под себя», и стороннего эксперта. Несколько месяцев все шло нормально: я находила небольшие ошибки разработчика, помогала обучать сотрудников Заказчика и расписывать права доступа. Наступил момент, когда зарплату водителям и механизаторам впервые должны начислить в программе из первичных документов (путевых листов и учетных листов трактористов-машинистов). Как всегда, до даты выдачи зарплаты осталось совсем немного времени. И тут обнаружилось, что некоторым водителям программа начислила зарплату на уровне директорской. Бухгалтеры-расчетчики хватаются за голову, виня себя во всех смертных грехах. Но просмотр записей в регистре накопления, которые делает путевой лист, показал, что в некоторых ситуациях документ-регистратор пишет в регистр двойные и тройные записи. Вызываем разработчика и показываем ему проблему.
«А чего это вы в регистр полезли?!» — вместо «спасибо» сказал разработчик, долго искал причину ошибки, но в конце концов её исправил. Потом он совещался с финансовым директором. А затем финансовый директор пригласил меня и предложил расторгнуть договор по взаимному согласию. «Насильно мил не будешь» — и я согласилась.
Поэтому причины моего скептического отношения к откату не столько моральные, сколько практические.
- · Во-первых, сложнее «наработать» на общую сумму по договору. Те люди, которые не участвуют в серой схеме, резонно будут задаваться вопросом: «За что столько платим?».
- · Во-вторых, процесс принятия решений в сложных проектных ситуациях будет искажаться личной заинтересованностью отдельных управленцев.
Слабые стороны сильного руководителя
Влияние личностных качеств руководителя на механизм принятия решений выражается понятием «стиль управления». В толковом словаре по управлению сказано: «Стиль управления — совокупность наиболее характерных и устойчивых методов решения задач и проблем, используемых руководителями организаций и предприятий в своей практической деятельности».
К факторам, определяющим стиль управления, которые выбирает руководитель, относят:
- · Умения и навыки пользоваться властью. Начинающий руководитель склонен использовать только волевые или только демократические приемы. Руководитель опытный выбирает приемы, наиболее действенные в каждой конкретной ситуации.
- · Психофизиологические особенности руководителя (темперамент, характер). Человек с сильным типом нервной системы более склонен к волевым решениям и менее к продумыванию последствий таких решений.
- · Социальные приоритеты, декларируемые обществом, и следование им в каждой местности. Так в «глубинке» подчиненные более склонны рассматривать руководителя как «царя, отца народа».
Авторитарный стиль руководства — наиболее проблемный с точки зрения работ по внедрению программных продуктов. Использующие такой стиль управления владельцы и руководители, обычно самостоятельно решают большинство вопросов, не считаясь с мнениями других, не терпят возражений подчиненных, постоянно ищут ошибки и нарушения, с целью примерно наказать виновных. С подчиненными у них складываются отношения «надзиратель-заключенный». Они не соблюдают служебную иерархию соподчинения. Старинный принцип управления «Вассал моего вассала — не мой вассал» — это не для них. Даже грамотных работников они принижают, пытаясь доказать свое превосходство. Автократ своим своеволием парализует работу коллектива, на который опирается. Запуганные, недовольные и обиженные подчиненные могут его подвести и дезинформировать. Они не только ненадежны, но и работают не с полной отдачей, пассивны, скрывают свои недостатки в работе. На таких предприятиях процветает угодничество и наушничество вместо работы с претензиями, искажено представление о действительном положении дел. Люди стараются избавиться от ответственности и больше всего хотят защищенности.
В защиту этого стиля руководства можно привести следующие доводы:
- · Подобные руководители эффективны для работы в критических ситуациях, когда нет времени на обдумывание решений. В краткосрочном периоде это дает определенный эффект, но в долгосрочном может привести к кризису.
- · Кадровые проблемы, особенно на периферии, могут создать у руководителя стереотип поведения и восприятия. В самом деле, несколько раз я присутствовала при процессе поиска главного бухгалтера на предприятие. Кандидатки описывали процесс формирования затрат на производство только как Дт20 Кт60, а вопрос «Что учитывается на счете 09» рассматривали как почти неприличный.
Случай из практики. Я участвовала в проекте, где в работу предприятия, находящегося в сложном финансовом состоянии, вмешалась управляющая компания от банка-кредитора. Все работы по ведению ИТ-проекта приказом поручили финансовому директору. Уже тот факт, что финдир вынужден был подчиняться и гендиректору УК, и собственникам, задало медленный темп ведения работ. Но когда процесс внедрения дошел до производственной лаборатории, он застопорился совсем, так как зав. лабораторией финдиру не подчиняется. Попытки финдира заранее информировать о проблемах руководителей (собственников и гендира УК) и привлечь их к преодолению этих проблем, успехом не увенчались. И только когда под угрозой срыва оказался новый заготовительный сезон, гендиректор УК вмешался в ситуацию.
Для начала он лишил премии финдира «за срыв учета», затем принялся за нас (внедренцев). Меня вызвали на совещание, где человек шесть устроили мне «суд Линча». Гендиректор УК сидел во главе стола «туча тучей». Мои старания перевести разговор в конструктивную плоскость успехом не увенчались. О своих просчетах другая сторона разговаривать не хотела. Приговор генерального директора был прост: нам заплатят за месяц работ, если мы к заготовительному сезону сделаем всё. Честное слово, задания, которые давала мачеха Золушке, были более исполнимыми, чем это требование. Любой внедренец знает, что «всё» может означать путь до Луны и обратно. У меня лежали в папке разрозненные требования разных сотрудников, причем некоторые из них уже казались нецелесообразными. Например, желание вместо ведения бумажного журнала учета лабораторных анализов вести его электронный аналог. Объяснения, что первичный бумажный учет необходим для контроля, не принимались. Я еще могла бы понять ситуацию, когда данные напрямую вносятся в программу с измерительных приборов. Но это был не тот случай. Или создание формы отчета, который делался службами один раз в месяц, причем алгоритм расчетов менялся в зависимости от разных ситуаций на производстве и изобиловал ручными корректировками. Создание этого отчета в Excel занимало пару часов, а разработка и отладка в ПП грозила занять несколько недель. Проблема была в том, что принять на себя ответственность за изменение или сокращение требований никто из сотрудников Заказчика не хотел.
После совещания я создала примерный план-график работ, в который включила все имеющиеся у меня пожелания. Естественно, ни сроки, ни объемы/оплата работ не устроила гендиректора УК и собственников. Начались наезды типа «Мы вас взяли, как специалистов, вы должны…». О том, что сроки и объемы должны определяться и корректироваться обеими сторонами по договору, представители Заказчика сначала говорить избегали. Тогда я создала примерный план-график работ, в который включила только самое необходимое с моей точки зрения. А на предприятии-Заказчике появились представители фирм, представляющих иные программные продукты. Сотрудник Заказчика, который сопровождал «1С:Предприятие», по секрету поведал мне, что такую чехарду с программой перед заготовительным сезоном он наблюдает уже четвертый (!) год. Понимая, что оплату за уже выполненную работу за последний месяц я, скорее всего, не получу, пишу письмо руководителю о том, что либо готова расторгнуть договор по взаимному согласию сторон, либо настаиваю на его соблюдении:
- · необходим письменный мотивированный отказ или подписанный акт о выполненной работе;
- · оплата выполненных работ;
- · согласование обеими сторонами Задания на внедрение на следующий месяц.
«Никогда не идите навстречу человеку, который настаивает на правомерности неправомерных требований». Желание гендиректора УК «продолжать работу по его требованиям» было неправомерно, но я была готова помочь Заказчику определиться в его истинных желаниях и приоритетах. Состоялось еще одно совещание у Заказчика, на котором обсуждались преимущества и недостатки трех программных продуктов.
К моему удивлению, здравый смысл победил, и работы с нами были продолжены.
Непрерывность против дискретности
Существует книга «Непрерывность против дискретности в языке и мышлении» Налимова В.В. В этой работе выдвинуто положение о принципиальной неразрешимости диалога человека с ЭВМ средствами формальной логики. Когда-то эта книга заставила меня по-новому взглянуть на процесс формирования требований Заказчика к работе программного продукта. Вот некоторые выдержки из книги:
«Есть две степени понимания. Первая, когда Вы изучили какой-нибудь вопрос и как будто знаете все, что нужно, но Вы еще не можете самостоятельно ответить на новый вопрос, относящийся к изучаемой области; и вторая степень понимания, когда появляется общая картина, ясное понимание всех связей. Такие вопросы, на которые нельзя ответить, пока этой второй степени понимания нет, мы называем парадоксами. Разбор подобных парадоксов очень полезен для достижения такого полного понимания.
Математики, особенно те, кто связан в своей деятельности с ЭВМ, не увидят каких-либо принципиальных трудностей для дискретных устройств по сравнению с непрерывными. И действительно, если нам, скажем, нужно найти площадь под кривой, не заданной аналитически, то это не вызовет особых неприятностей, если с кривой могут быть считаны точки с любым, сколь угодно малым шагом. Но нелепой была бы сама постановка задачи, если нам было бы дано только кодовое обозначение кривой и весьма нечеткое ее описание через кодовые обозначения других, таким же образом заданных кривых.
А в языке мы именно с этим и сталкиваемся: нам известно слово – кодовое обозначение смыслового поля – и некое неясное описание этого поля, данное через другие, такие же кодовые обозначения. Все многообразие смыслового содержания остается скрытым – оно выявляется только через потенциально заложенную возможность построения безграничного набора фраз. Континуальное смысловое содержание, стоящее за дискретными символами языка, оказывается принципиально неизмеримым. Нам доступны отдельные его фрагменты, возникающие у нас при интерпретации тех или иных фраз.
Человеку свойственна дискретная (частями) система восприятия, когда сознание лучше анализирует и усваивает объемную информацию только после предварительного разделения ее на определенное количество частей.
Дискретность нашего языка является неоспоримым свидетельством дискретности нашего восприятия.»
Дискретностью восприятия человека объясняется то, что большинство сотрудников на проекте по внедрению способны лишь фрагментарно объяснить суть своей работы и также фрагментарно воспринимать те новшества, которые несет программный продукт. Дискретностью восприятия объясняется то, что полный алгоритм поведения программного продукта появляется только после процесса его опытной эксплуатации, а иногда и позже. Парадокс внедрения состоит в том, что пользователь что-то знает, но не знает, что именно нужно узнать внедренцу. «Правильно поставленный вопрос обычно содержит 70% ответа». Следовательно, внедренцу нужно собрать именно эти 70% знаний по предмету, чтобы задать пользователю правильный вопрос. Вот поэтому пользователи часто спрашивают: «А у вас есть опыт внедрения в этой области?».
С точки зрения управления, на предприятии должен быть такой документ, как Учетная политика предприятия, в котором должны быть описаны правила и взаимосвязи учета. Но лишь пару раз за свой шестнадцатилетний опыт внедрений я видела достаточно полную Учетную политику. Большинство ограничивается формальным описанием и набором фраз типа: «распределение косвенных расходов ведется согласно НК РФ». И некоторые главные бухгалтера объясняют краткость учетной политики именно тем, что так легче защищать перед налоговой инспекцией особенности учета на предприятии. Да и создать полноценную Учетную политику — адский труд, тем более под УПП.
Внедренцы пытаются защититься, создавая ТЗ и предлагая Заказчику его подписать. Но рано или поздно на проекте возникает проблема расхождения подписанного ТЗ и пожеланий Заказчика. И эта проблема может перерасти в вопрос о возможности совместного продолжения работ.
Случай из практики. Проблема внедрения, описанная в предыдущем разделе, имела еще одно простое объяснение: данные БУ не всегда совпадали с фактическими данными. Выставление претензий к контрагенту дело весьма хлопотное. К тому же с каждым контрагентом руководство согласовывало свой вариант урегулирования разногласий. При дальнейшем внедрении обнаружились еще ряд нестыковок УУ и БУ. Но об этом сотрудники Заказчика умалчивали. Конечно, мы справились с ситуацией, но как говорят:
«Никогда еще Штирлиц не был так близок к провалу».
