Почему компании не внедряют новые технологии, даже когда для этого есть все ресурсы?

Евгений Равич пишет:

Антон Соболев пишет:
На выходе получился набор паутинообразных диаграмм (radar charts) с указанием на пересечение областей покрытия требовавшегося заказчику функционала. Это позволило наглядно сравнить ширину и глубину фактических возможностей, а также потенциала каждой единицы софта.

Radar Charts - это замечательно. Рад, что их хватило.

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

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

Оценить функционал, степень соответствия требованиям и - тем более - трудоёмкость реализации без тестирования практически невозможно. Условно базовые вещи делают многие, дальше начинаются неожиданности. Дьявол в деталях.  В этом проблема больших IT проектов.

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

Антон Соболев пишет:

Евгений Равич пишет:

Антон Соболев пишет:
На выходе получился набор паутинообразных диаграмм (radar charts) с указанием на пересечение областей покрытия требовавшегося заказчику функционала. Это позволило наглядно сравнить ширину и глубину фактических возможностей, а также потенциала каждой единицы софта.

Radar Charts - это замечательно. Рад, что их хватило.

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

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

Оценить функционал, степень соответствия требованиям и - тем более - трудоёмкость реализации без тестирования практически невозможно. Условно базовые вещи делают многие, дальше начинаются неожиданности. Дьявол в деталях.  В этом проблема больших IT проектов.

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

Кто был исполнитель по контракту? Свм заказчик, вендор, интегратор, коллективное творчество, другое?

Дмитрий Нор пишет:

Евгений Равич пишет:

Антон Соболев пишет:
На выходе получился набор паутинообразных диаграмм (radar charts) с указанием на пересечение областей покрытия требовавшегося заказчику функционала. Это позволило наглядно сравнить ширину и глубину фактических возможностей, а также потенциала каждой единицы софта.

Radar Charts - это замечательно. Рад, что их хватило.

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

Оценить функционал, степень соответствия требованиям и - тем более - трудоёмкость реализации без тестирования практически невозможно. Условно базовые вещи делают многие, дальше начинаются неожиданности. Дьявол в деталях.  В этом проблема больших IT проектов.

Согласен. Когда делается большой проект могут появиться 'подводные камни' в процессах заказчика и договоренности, которые были на старте могут не сработать. Тут и появляются проблемы: не хватает бюджета, не работает софт так, как задумывалось, процессы внутренние поменять невозможно и т.п. Поэтому мы дошли до того, что не пишем полное подробное ТЗ в деталях, а прописываем концепцию и суть с основными деталями и если это все заработает нормально у заказчика - заключаем договор на техподдержку и уже в ходе техобслуживания дорабатываем детали. Такой метод на практике наиболее жизнеспособный в больших проектах. Но это на нашем опыте. У других может быть по другому и далеко не все заказчики соглашаются работать нашими методами

Состав и содержание проектных документов обсуждается с заказчиком. Это понятно. Что-то корректируется в ходе проекта в соответствии с согласованной процедурой.

То же касается и зон ответственности.

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

А существующие у заказчика процессы проще обсуждать, детализировать и описывать в рамках предпроектного обследования. Экономит много времени. Иногда и заказчик не до конца знает, как это  у него устроено, и/или что-то на каком-то шаге делается неформально и вручную, или он уже хотел бы что-то поменять после внедрения новой системы. Тут есть, о чём подумать и поговорить.

Евгений Равич пишет:

А существующие у заказчика процессы проще обсуждать, детализировать и описывать в рамках предпроектного обследования. Экономит много времени. Иногда и заказчик не до конца знает, как это  у него устроено, и/или что-то на каком-то шаге делается неформально и вручную, или он уже хотел бы что-то поменять после внедрения новой системы. Тут есть, о чём подумать и поговорить.

Круто было бы так делать. Отлично было бы, чтобы предпроектное исследование проводилось нормально. Но очень часто на практике за предпроектное обследование никто не хочет платить. Резко прилетает задание с общим описанием и говориться, что сроки уже поджимают и надо делать. Тендеры проводятся также: ТЗ пишется в общих чертах похожее, а потом уже делай его как хочешь. Отсюда и проблемы. Мне кажется тут и корень проблемы ,что внедренное ПО нормально не работает, именно на этой стадии (предпроетного обследования). Мало где сейчас зрелый подход к цифровизации, а он как раз предполагает нормальное предпроектное обследование

Дмитрий Нор пишет:
Круто было бы так делать. Отлично было бы, чтобы предпроектное исследование проводилось нормально. Но очень часто на практике за предпроектное обследование никто не хочет платить.

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

Тут скорее вопрос затрат на командировки. Если Заказчик в Вашем городе (или там, куда можно одним днем подъехать), то подъехать к нему и по месту ознакомиться с тем, что придется делать больших проблем не должно представить.

Если в другом городе, то тут немного сложнее, надо чтобы Заказчик прислал необходимые материалы.

Евгений Равич пишет:

Кто был исполнитель по контракту? Свм заказчик, вендор, интегратор, коллективное творчество, другое?

Исполнителем и интегратором на проекте был сам вендор. Куратором интеграции и техническими писателями выступали консультанты. Заказчик выдвигал пожелания и описывал предметную область TO-BE.

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

Специально применялись только западные технологии, без всяких "адаптаций" (в т.ч. документация на англ.), и они "из коробки" прекрасно сработали в России. Получилось на практике опровергнуть миф о "принципиальной невозможности", "особом пути" и прочей ерунде. Если делать нормально - нормально и выйдет.

Антон Соболев пишет:
Если делать нормально - нормально и выйдет.

Именно так. И нормально должны делать все.

Дмитрий Нор пишет:

Евгений Равич пишет:

А существующие у заказчика процессы проще обсуждать, детализировать и описывать в рамках предпроектного обследования. Экономит много времени. Иногда и заказчик не до конца знает, как это  у него устроено, и/или что-то на каком-то шаге делается неформально и вручную, или он уже хотел бы что-то поменять после внедрения новой системы. Тут есть, о чём подумать и поговорить.

Круто было бы так делать. Отлично было бы, чтобы предпроектное исследование проводилось нормально. Но очень часто на практике за предпроектное обследование никто не хочет платить. Резко прилетает задание с общим описанием и говориться, что сроки уже поджимают и надо делать. Тендеры проводятся также: ТЗ пишется в общих чертах похожее, а потом уже делай его как хочешь. Отсюда и проблемы. Мне кажется тут и корень проблемы ,что внедренное ПО нормально не работает, именно на этой стадии (предпроетного обследования). Мало где сейчас зрелый подход к цифровизации, а он как раз предполагает нормальное предпроектное обследование

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

А мелкие бывает не понимают этой необходимости. Тогда можно договариваться о прототипе системы, или об опытной эксплуатации. Но ОЭ не должна затягиваться, ну пусть это будет месяц, с выставлением конкретных замечаний. 

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

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

Хм...Четыре года обследование и выбор? Поясните, пожалуйста, это очень долго. Это, на мой взгляд, уже не взлетит.

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

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

А мелкие бывает не понимают этой необходимости. Тогда можно договариваться о прототипе системы, или об опытной эксплуатации. Но ОЭ не должна затягиваться, ну пусть это будет месяц, с выставлением конкретных замечаний. 

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

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

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

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

Дмитрий Нор пишет:
Надо работать с теми, кто делает все правильно

Кто бы это мог бы гарантировать.

Но, для начала, нужно потренировать себя, возможности для улучшений есть всегда. Новые темы, новые категории заказчиков, новые процессы, новые продукты. Что-то можно тестировать заранее, готовить демо и рассказывать о своём опыте.

Анатолий Курочкин пишет:

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

Хм...Четыре года обследование и выбор? Поясните, пожалуйста, это очень долго. Это, на мой взгляд, уже не взлетит.

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

Немного не так. Весь проект занял около 4 лет. Возможно, удалось бы и быстрее, но ковидные ограничения по международным перелетам, да и сами болезни людей немного  (думаю, в пределах квартала) притормозили скорость.

Если говорить про разделение - проект шел в несколько фаз.

На первой фазе (scoping session - примерно 1,5-2 мес.) были собраны пожелания заказчика и проведен ряд подпроектов по диагностике AS-IS, что вылилось в документацию TO-BE.

На второй фазе (system selection - около 3 мес.) отбирался софт, способный удовлетворить требования в документации - так раз те опросники по 1000+ вопросов, которые заполняли вендоры. Здесь большую часть времени составило ожидание ответов.

На третьей и основной фазе (scope implementation) помодульно внедрялись блоки системы, и это требовало вовлечения различных людей из многих стран.

Если условно SAP принять за Windows XP, система, которая развертывалась (не стану называть: NDA), соотносилась бы с ним как Windows 10 PRO. Какие-то модули были внедрены раньше, какие-то - позднее, но внедрены были все задумки, поэтому по факту взлетело.

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

Антон Соболев пишет:

Анатолий Курочкин пишет:

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

Хм...Четыре года обследование и выбор? Поясните, пожалуйста, это очень долго. Это, на мой взгляд, уже не взлетит.

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

Немного не так. Весь проект занял около 4 лет. Возможно, удалось бы и быстрее, но ковидные ограничения по международным перелетам, да и сами болезни людей немного  (думаю, в пределах квартала) притормозили скорость.

Если говорить про разделение - проект шел в несколько фаз.

На первой фазе (scoping session - примерно 1,5-2 мес.) были собраны пожелания заказчика и проведен ряд подпроектов по диагностике AS-IS, что вылилось в документацию TO-BE.

На второй фазе (system selection - около 3 мес.) отбирался софт, способный удовлетворить требования в документации - так раз те опросники по 1000+ вопросов, которые заполняли вендоры. Здесь большую часть времени составило ожидание ответов.

На третьей и основной фазе (scope implementation) помодульно внедрялись блоки системы, и это требовало вовлечения различных людей из многих стран.

Если условно SAP принять за Windows XP, система, которая развертывалась (не стану называть: NDA), соотносилась бы с ним как Windows 10 PRO. Какие-то модули были внедрены раньше, какие-то - позднее, но внедрены были все задумки, поэтому по факту взлетело.

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

Понял! Благодарю! Всё очень логично!

Антон Соболев пишет:

Анатолий Курочкин пишет:

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

Хм...Четыре года обследование и выбор? Поясните, пожалуйста, это очень долго. Это, на мой взгляд, уже не взлетит.

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

Немного не так. Весь проект занял около 4 лет. Возможно, удалось бы и быстрее, но ковидные ограничения по международным перелетам, да и сами болезни людей немного  (думаю, в пределах квартала) притормозили скорость.

Если говорить про разделение - проект шел в несколько фаз.

На первой фазе (scoping session - примерно 1,5-2 мес.) были собраны пожелания заказчика и проведен ряд подпроектов по диагностике AS-IS, что вылилось в документацию TO-BE.

На второй фазе (system selection - около 3 мес.) отбирался софт, способный удовлетворить требования в документации - так раз те опросники по 1000+ вопросов, которые заполняли вендоры. Здесь большую часть времени составило ожидание ответов.

На третьей и основной фазе (scope implementation) помодульно внедрялись блоки системы, и это требовало вовлечения различных людей из многих стран.

Если условно SAP принять за Windows XP, система, которая развертывалась (не стану называть: NDA), соотносилась бы с ним как Windows 10 PRO. Какие-то модули были внедрены раньше, какие-то - позднее, но внедрены были все задумки, поэтому по факту взлетело.

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

Были ли требования по интеграции? Если да, то кем и как проверялась техническая возможность их выполнения?

Если нет, то сколько по времени заняло третья фаза?

Евгений Равич пишет:

Были ли требования по интеграции? Если да, то кем и как проверялась техническая возможность их выполнения?

Да, были. Возможность проверялась сперва нами по итогам анализа опросников, затем - IT-департаментом заказчика и подтверждалась командой инженеров вендора.

Дополнительно была развернута "песочница", в которой воспроизвели изолированный контур для in-house применения софта и тестирования заявленных характеристик. По умолчанию вендор предлагал облачное развертывание, но в целях большей безопасности заказчик настоял на портировании системы на внутренних серверах, без доступа извне.

Если нет, то сколько по времени заняло третья фаза?

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

Анатолий Курочкин пишет:
В крупных компаниях обычно с обследованием проблем не возникает. Но оно не должно сильно затягиваться. У вас уже должны быть готовы предварительные схемы, паттерны, шаблоны, образцы, как хотите это называйте. 

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

На основании этого делалось технико-коммерческое предложение (ТКП), которое направлялось Заказчику.

Если заключался контракт, то мы практически сразу приступали к проектным работам и закупкам комплектующих, уточняя с Заказчиком по мере этого необходимые детали и согласовывая возникающие вопросы.