Executive.ru предложил для решения кейс участника Сообщества Александра Кудряшова «Информационная система ценою подешевле».
Решение победителя кейса Дмитрия Ольшанского:
1. Какое решение по системе примет ББ?
Прежде чем предполагать, как поступит ББ, давайте рассмотрим, в какой ситуации он сейчас оказался.
Причины, по которым он решил разрабатывать IT-систему (какую проблему хотел решить и почему именно сейчас), к сожалению, неизвестны. Понимай их НГ, уверен, ситуация бы не зашла в тупик. Как главный критерий ББ имел только цену, как второстепенные критерии – пожелания к функционалу. В результате цена стала завышенной, но тех самых его пожеланий в результате не оказалось. Иными словами, ни один ключевой критерий заказчика не был удовлетворен.
В данный момент ББ имеет:
- отсутствие критериев оценки информатизации;
- наполовину оплаченный продукт;
- противоречия в коллективе;
- выполненный критерий «внедрение информатизации».
Вероятные сценарии поведения
Один из вариантов – спасти уплаченные деньги. Вызвать к себе специалистов, которые хвалили программу, для консультаций, чем эта программа может быть полезна и что еще с нее можно взять. Уполномочить сотрудника отдела для дальнейшего кураторства и внедрения. ЗД будет лишена премии за некомпетентность (на нее будут списаны все грехи для сохранения лица шефа). С компанией-исполнителем после внедрения продукта отношения продолжаться не будут.
Компания нашего героя получит относительную головную боль при внедрении продукта, так как к ней будут цепляться по всей строгости к каждой мелочи, как результат – временные затраты будут больше, чем планировалось.
Второй вариант – получение желаемого. На исполнителя будет оказываться давление с целью получения желаемых параметров. В переговоры будет выставляться представитель из наиболее недовольного отдела. Поскольку воплотить желаемые параметры не будет возможности, в защиту могут выставляться бонусы, скидки, другие дополнительные параметры и т.д. (то, что на самом деле и преследовалось). Давление будет до тех пор, пока исполнитель не «вывернется на изнанку» и не покажет, что больше дать не может. В результате амбиции ББ будут удовлетворены, и он прекратит отношения с исполнителем, гордо и победно подняв подбородок.
2. Есть ли победители и проигравшие в данном проекте?
К сожалению, и заказчик, и исполнитель не являются победителями.
Заказчик, как указано выше, не получил требуемых параметров, а исполнитель может не рассчитывать на дальнейшее сотрудничество. В организациях, как правило, первая сделка редко приносит прибыль, главная задача – получить постоянного клиента.
3. Оцените линию действий Заказчика и Исполнителя и укажите на их ошибки.
В первую очередь рассмотрю ошибки продавца. Рассматриваю с точки зрения выгоды сделки и сохранения клиента.
Первая ошибка – НГ не узнал, какую проблему хотел решить ББ и почему именно сейчас. И как первый ход он предложил минимальную цену, чтоб войти «поздороваться». Лучшим был бы вариант выступить консультантом, рекомендованным ЗД, для того, чтобы выяснить полностью запросы ББ, отстроить эти запросы под продукт своей компании. С помощью этих запросов осмотреть рынок предложений, сориентироваться по цене решения. То, что ББ руководствовался только ценой, говорит о том, что других критериев у него не было. И задача НГ была в том, чтобы создать эти критерии. Если отойти в сторону от темы, цена – это стоимость решения проблем. Можно понижать цену, а можно увеличивать ценность решения проблем. Как правило, если идет торг, нужно не цену сбивать, а спрашивать, что еще можно на эти деньги получить.
Вторая ошибка заключалась в том, что запрос ББ был попросту вырезан из ТЗ, хотя на нем необходимо было сосредоточиться максимально, а вместо этого его отбросили. Как результат ББ не получил вообще ничего из того, что заказывал. Если какие критерии и были удовлетворены, то те, которые не были на первых местах у заказчика.
Третья ошибка – саботаж Excel-группы. Желательно было предусмотреть, выяснить причины такой реакции и либо прийти к общему знаменателю, либо найти способ заблаговременно обесценить их участие, сосредоточив внимание на конструктивном отделе. Уверен, ББ прекрасно понимал, что при внедрении перемен будет мало тех, кто не уверен, что будет лучше, и будет много тех, кто уверен, что будет хуже.
Ошибки Заказчика – несформированные критерии и запросы, некомпетентный куратор, неосведомленный о приоритетах проекта. ББ, если сам был инициатором и заинтересованным лицом, и должен был лично принимать окончательное ТЗ. При этом ББ самоустранился от решения выданного запроса, выставив впереди себя некомпетентное лицо, делегировав полномочия, не делегировав ответственность.
4. Приведите рекомендации, как надо было работать Заказчику и Исполнителю, чтобы не попасть в подобную ситуацию.
Рекомендация Исполнителю: не заходить с низкой цены, стремиться понять, что хочет клиент. Понимать, чего хочет от сделки сам и что может дать взамен. Отказаться от сделки, если не может выполнить условия с выгодой для себя и партнера. В этом случае получит прочную репутацию и может быть рекомендован как специалист друзьям несостоявшегося заказчика.
Рекомендация Заказчику: держать обратную связь, утверждать ключевые этапы лично или поручать ответственному лицу.
Комментарий автора кейса:
Основные истоки проблем, описанных в кейсе, заложены в названии «Информационная система ценою подешевле». И каждое действующее лицо внесло свой вклад в коллизии кейса. Рассмотрим эти взносы в порядке убывания значимости в дело общего провала проекта.
Есть фундаментальный принцип, зародившийся еще на заре автоматизации: участие и заинтересованность первого лица заказчика в создаваемой информационной системе. В данном случае ББ был заинтересован только в минимальной стоимости разработки и, что замечательно, он до начала работ уже знал эту цифру, сколько платить исполнителю! А его участие ограничилось только делегированием проекта целиком и полностью на явно неподготовленного сотрудника, а также начальственным разносом участников проекта. Чего явно мало для успеха софтверного проекта. При этом, в отличие от евроремонта квартиры, когда одна бригада гастарбайтеров продолжает работу уволенных предыдущих, выгнать одних разработчиков информационных систем и нанять других, в надежде что новые продолжат начатую работу и поэтому им надо меньше денег, тут так не получится. Тут получится, что скупой платит дважды.
Руководитель проекта, заместитель директора, взялась за непосильную для нее работу и мало сделала, чтобы научиться чему-то в этой области (ведь ТЗ писал за нее Исполнитель). Но еще можно было бы не провалить проект, если бы она разобралась в отношениях и интересах различных групп сотрудников, заняла бы свою принципиальную позицию, не пошла на поводу у приближенной к ББ группы Excel и более тесно и открыто работала с исполнителем. Но она не рискнула вступить в конфронтацию и пошла по пути быть хорошей для всех, поэтому осталась одна и проиграла.
Исполнитель, НГ, хотел поймать рыбку на живца, потрафив пороку жадности ББ. И это сначала сработало, контракт он получил за счет демпинга. Но поскольку полученная сумма едва покрывала заданный в ТЗ функционал, его свобода по поводу реализации новых функций, затребованных группой Excel, была ограничена. Он лишился своего важного менеджерского маневра – подключать дополнительные ресурсы. А такой запас при создании информационных систем просто необходим. Кроме того, он не сумел нейтрализовать противников проекта – группу Excel, в том числе путем активации сторонников из других сотрудников.
Этот кейс имел прототипом реальный случай, во многом совпадающий по действующим лицам и поведению основных участников кейса. Кейс оканчивается разносом от ББ. Далее события разворачивались так. ББ дал команду закрыть работы по системе по факту и ограничить оплату только уже выплаченным авансом. НГ после обсуждения ситуации в своей компании решил не бороться за полную оплату (хотя сделано было дел примерно на 90%). Основная причина, что от этого ББ больше не выжмешь, а также и потому, что наработки по данному проекту хорошо вписывались в новый заказ, поступивший в компанию.
Через месяц от Заказчика ушла (по воле ББ) руководитель проекта. Потом ББ поручил информатизацию другому лицу, стали искать новых исполнителей, опять по принципу «подешевле». Но и спустя год после этого случая эта компания так и не создала новую систему и работает по старинке, с еще большим доверием и привилегиями от ББ для группы Excel.
Как мне представляется, авторы всех решений являются профи в управлении софтверными проектами, имеют богатый опыт взаимодействия с Заказчиком и хорошо понимают как явные, так и скрытые мотивы тех коллизий, которые описаны в кейсе. В каждом решении есть глубокие и точные мысли по поводу поведения героев кейса.
Поэтому и обидно, что их мнения (а за ними и других участников) не прозвучали в дискуссии по кейсу, важной причиной чего я считаю условие администрации портала о том, что высказанные при обсуждении и анализе кейса толкования и формулировки не могут считаться решениями. Наверное, многими это расценивается просто как запрет на обсуждение. А жаль, поскольку именно в процессе дискуссий и возникает тот результат, который понимается и является практически полезным для участников обсуждения и читателей форума.
Наиболее полное, учитывающее различные обстоятельства и модели поведения его героев, решение кейса представил Дмитрий Ольшанский.
Источник изображения: pixabay.com
