https://dzen.ru/a/ZBLyYlIMEndFLyy9?share_to=telegram
Должностная инструкция аналитика 1С

Сегодня обсуждали с коллегий проблему, которая возникает очень часто при продаже проектов.

1. Клиент хочет узнать стоимость проекта и зафиксировать ее в договоре.
2. Исполнитель не имеет достаточно информации о границах проекта и спецификации конечного продукта. И предлагает сначала провести предпроектное обследование.

Диалог строиться примерно так:
- Вот вам материалы, ждем от вас коммерческое предложение с указанием фиксированных стоимости и сроков проекта.
- Хорошо, мы изучим материалы, при необходимости зададим вопросы.

материалы получили убогие

- Материалы, которые мы получили не содержат достаточной информации для оценки проекта. Предлагаем провести предпроектное обследование, после которого дадим точную оценку.
- Нет, мы не готовы брать на себя риски и ввязываться в проект без фиксированных стоимости с сроков проекта. Мы вам предоставили все материалы, если вам нужно дополнительная информация, то задавайте нам вопросы сейчас, мы вам ответим.
- Ваши ответы на коротких встречах или переписке не помогут. Требуется провести обследование.

Ну а далее взаимодействие, после нескольких раундов переговоров, может развиваться по трем сценариям:
1. Исполнитель дает оценку, которая устраивает заказчика и подписывается договор с фиксированной стоимостью. Дальнейшая судьба подрядчика плачевна - он в рабстве на галерах до тех пор, пока господин не решит его отпустить.
2. Исполнителя вежливо (иногда и не очень) посылают.
3. Заказчик принимает разумные объяснения и соглашается на предпроектное обследование (бинго).

Но есть ли еще варианты?

Мне кажется есть четвертый вариант, который может устроить обе стороны.

В договоре зафиксируются стоимость и сроки проекта, но с оговоркой, что если после проведения предпроектного обследования, новая оценка проекта увеличивается на какой-то процент (например, 10%), то стороны стороны договариваются, и далее снова три варианта:
1. Заказчик соглашается на сокращение или изменение требований к конечному продукту, чтобы уложиться в бюджетное ограничение.
2. Заказчик соглашается на увеличение стоимости и сроков проекта, на основании обоснованных доводов исполнителя.
3. Стороны расторгают договор по обоюдному согласию.

Кто-то скажет, что чем это отличается от предыдущих вариантов развития событий. Могу возразить. Если заказчику предложить четвертый вариант, то он получает, то на чем настаивал - фиксированную оценку проекта. При этом понимая, что если существуют бюджетные ограничения проекта, то должны быть и границы его ожиданий от конечного результата.

Ну а для тех, кто этого не понимает, есть такое изречение "кто ищет волшебника, то как правило находит сказочника".

https://dzen.ru/a/ZBSEoJHIyUYPEP1n?share_to=telegram
Границы проекта: как с ними работать?

Опишу сейчас ситуацию, в которую угодили накануне закрытия проекта. Проект по внедрению 1С:ERP закрывается по договору 3 апреля. Осталось до окончания опытной эксплуатации буквально несколько недель. В этот момент фирма 1С выпускает новый релиз конфигурации 1С:ERP. Заказчик требует выполнить в рамках бюджета проекта обновление конфигурации (доработанной). Осложняется это обстоятельство тем, что у нас в ТЗ прописано, что критерием приемки работ является сдача бухгалтерией актуальной отчетности за 1 квартал 23 г. В новом релизе 1С:ERP, естественно, появились изменения в отчетности по НДС. Теперь у РП есть несколько основных вариантов развития ситуации:
1. Настаивать на том, чтобы закрыть проект в прежнем релизе конфигурации, а обновление вынести за рамки проекта и отдельный бюджет (последствия этой позиции пока не понятны).
2. Выполнить обновление (где-то 3-4 недели работы команды из 5-6 человек) в рамках текущего проекта, снизив существенно рентабельность проекта.
3. Договориться о заказчиком частично возместить затраты на обновление.
4. Сделать обновление только в части бухгалтерской отчетности.
Может есть и другие варианты.
А что бы предложили вы в этой ситуации?

Подробное рассмотрение темы "Управление рисками проекта"

https://dzen.ru/a/ZB2160QQwX027cKk?share_to=telegram

https://dzen.ru/a/ZB9B7EQQwX02KrFz?share_to=telegram
В чем разница между допущениями и ограничениями проекта?

📎 Вчера были на встрече с клиентом - известная сеть клиник. Получил удовольствие от общения с заказчиком.

Немного об общей атмосфере встречи.

Со стороны клиента: ИТ-директор, операционный директор (бывший руководитель по закупкам)
и зам. директора по закупкам.

Первые слова прозвучали примерно так: "с такой ценой, которую вы указали в предложении, нам не о чем здесь разговаривать".

В дальнейшем, беседа строилась в той же манере - одни манипуляции, очень характерные для закупщиков. Вот перечень шаблонных фраз (точно не процитирую, но смыл остался), которые мы услышали : "по вашему предложению видно, что у вас нет опыта решения подобных задач", "у нас все стандартно, как у всех, поэтом не может быть так дорого", "стоимость вашего предложения самая высокая", "у нас много претендентов на этот проект и мы выбираем", "мы хотим увидеть в вашем предложении стоимость решения под ключ", "если вам что-то не понятно, задавайте вопросы и мы ответим", "мы не готовы брать риски на себя". В общем, все по классике.

При этом, было заметно, что в нас заинтересованы. Почему? 1. Переговоры шли достаточно долго, хотя неоднократно нам говорили, что дальше разговаривать не о чем.
2. От нас ждут наше новое предложение и готовы его обсуждать.
3. С нами долго общалась IT-служба перед этими переговорами, которая выясняла наш опыт и подход к решению таких задач. Т.е. это не случайный "наезд", а продуманная торговая стратегия.
4. Клиента поджимают сроки и им необходимо выбрать команду для старта проекта. Требуется узкая специализация для решения задач проекта. Т.е. такие компетенции сравнительно редки.
5. С одной командой, которая проводила предпроектное обследование, они расстались, видимо, не устроила цена, которую подрядчик назвал после обследования. И еще одна ошибка в выборе подрядчика (по цене) повлечет последствия для проекта и его участников.

Другими словами, если бы не были заинтересованы, либо встреч не состоялась, либо переговоры завершились очень быстро.

Как готовиться и вести себя на таких переговорах?

1. Необходимо заранее готовиться. Мы, к сожалению, не были готовы. Пришли знакомить команду с заказчиком, а получили "наезд". Готовиться - это значит определить свою стратегию переговоров (желательно провести SWOT анализ перед встречей, который очень хорошо приводит мысли в порядок).
2. Держать себя достойно и уверенно.
3. Знать и использовать свои сильные стороны. Выяснить слабости противоположной стороны. Это позволит вам определить степени свободы для маневров.
4. Не стремиться договориться здесь и сейчас, тем более любой ценой. Не предлагать сразу скидки и доп. работы, чтобы угодить клиенту. Это всегда воспринимается, как слабость.
5. Не надо эмоционально реагировать на манипуляции, чего и добивается любой манипулятор.
6. Иметь заготовленные сценарии предложений. Сначала предлагается клиенту самый выгодный для нас сценарий, потом, при необходимости, уступаем немного. Главное, чтобы было куда отступать. Не отступать в одностороннем порядке, Уступка за уступку.
8. Держать паузу. Лучше всего сказать, что надо обдумать и все взвесить, а потом выйти с новым предложением.

К переговорам следует относится как к игре в стратегию. Мы должны собирать информацию о клиенте, анализировать и заранее продумывать наши шаги. Только так заключаются успешные сделки.

P.S. В нашем случае, сделаем усилия, чтобы договориться. Но если клиент "невменько", тогда сделки не будет. Такое тоже бывает.

https://dzen.ru/a/ZCRto-WQ9SyHZiL6?share_to=telegram
Искусственный интеллект (ChatGPT) на службе аналитика

Рефлексия участников обучения в Школе аналитика (февраль 2023) на тему достоверности экспертных оценок.

Коллеги, в оценке портфеля был применен метод номинальной группы.

В групповом обсуждении могут возникать ситуации, когда группа совместно принимает неверное решение, противоречащее мнению большинства или даже мнению каждого. Статьи в Википедии: парадокс Абилина, групповое мышление, спираль молчания.

В качестве контрмер часто называют свободную коммуникацию, назначение "адвоката дьявола", использование сторонних или даже случайных экспертов. Все эти меры не работают.

Метод номинальный группы избегает ловушек группового мышления путем изоляции экспертов и анонимности оценок. Название "номинальная группа" означает, что группа является группой только номинально (фиктивно).

Кроме номинальной группы в ГОСТ Р 58771-2019, приложение Б, раздел Б.1 «Технологии выявления мнения причастных сторон и экспертов» предлагает и другие методы выявления мнений

Б.1.2 Мозговой штурм
Б.1.3 Метод Делфи (Delphi)
Б.1.5 Структурированные или полуструктурированные интервью
Б.1.6 Опросы

Приоритеты определились - три лидирующие темы, по результатам опроса. Забыли ещё добавить тему, связанную с продажами проектов. Надеемся, что эта тема тоже будет полезна для подписчиков.

Получил от клиента сегодня такое сообщение:

"У нас катастрофическая проблема с русский языком в результирующих документах. Не однократно по рабочим группам в рамках бизнес процессов делают замечания, а дело не двигается. Попроси что в зоне вашей ответственности проверить документы еще раз. Стыдно сдавать в таком виде … дай слово что поправите.".

Проект выполняем совместно с крупной консалтинговой компанией.

Честно говоря, действительно стыдно. Работаем в hi-tech, а элементарной грамоте не обучены.

Читаем статью Александра Мирзахмедова "Слонов едят по частям" о важности декомпозиции проектных задач.
https://dzen.ru/a/ZCZ_C1UqlhHAZFIM?share_to=telegram