Что такое предпроектное обследование

Предпроектное обследования при разработке информационной системы

Что бывает без предпроектного обследования?

В свое время мне пришлось заниматься разработкой и продажей систем для составления маршрутов транспорта: на карту выводятся точки с заказами, обводишь их мышью и размещаешь в машины. Обращается к нам одна компания с просьбой продать приложение. Не один месяц мы пытались выяснить, зачем же им подобная система нужна, в результате продали им «коробку», очень уж они просили. Затем решила данная компания привлечь нас для внедрения. И тут выяснилось, что в первую очередь им нужна была функциональность для учета топлива, которая в нашей системе отсутствовала от слова совсем.

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

Основные вопросы, на которые отвечает обследование

Как говорится, вам надо понять, ЧТО, ГДЕ, КОГДА. А именно:

Зачем нужно писать, почему недостаточно обсудить и проговорить?

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

Да, составление документов — дело кропотливое и иногда неприятное, но оно того стоит. Мысль ценна только тогда, когда она сформирована, а сформирована она тогда, когда сформулирована на бумаге.

Что должно содержать в себе предпроектное обследование?

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

Результатом исследования может быть целый пакет документов (часть из них приведена в конце статьи). Центральным (и, к сожалению, часто единственным) документом у меня обычно является документ «Концепция системы». Этот документ мы и обсудим в настоящей статьей.

Разрабатывая собственную структуру Концепции, я взял за основу отчет, подготавливаемый согласно ГОСТ 34 на стадии «Формирование требований к АС» (см. стандарт РД 50-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»). Но при этом внес свои дополнения.

«Концепция системы» может содержать 2, а иногда и 30 страниц. Все зависит от постановки задачи. «Концепция», как правило, согласовывается с высшим руководством заказчика, и только на основании этого можно разрабатывать Техническое задание.

Цель создания (модернизации) системы

Под целью создания я понимаю именно бизнес-цели. «Автоматизировать» — это не цель. Добавить функцию — тоже не цель. И «оптимизировать» — не цель. Например, сидит сотрудник и пару часов в день он может поспать прямо на рабочем месте (реальный случай, кстати). И кто-то просит автоматизировать его деятельность. Зачем? Чтобы он четыре часа спал?

За несколько лет анализа десятков проектов удалось определить только пять возможных целей создания (модернизации) системы:

Идея системы

В случае, если документ «Концепция» получается достаточно объемным, имеет смысл вначале кратко изложить самую суть системы, ее идею. Например, вы хотите создать какую-либо специализированную социальную сеть (ходите по музеям и делитесь впечатлениями). Я бы вначале описал потребность в общении между посетителями, а затем кратко — суть: разрабатывается мобильное приложение, в котором пользователь может написать свои впечатления от того или иного экспоната.

Сравнение старого и нового

Самым эффективным способом понять суть создаваемой системы — идти как бы от противного.

Для этого необходимо:

На чем собираемся зарабатывать

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

Заинтересованность сторон

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

Описание автоматизируемых процессов

Цель данного раздела — дать общее, но полное представление о процессе. Например, вы разрабатываете интернет-магазин. Очевидно, что нужен каталог, корзина, интеграция с банком-эквайером и доставка. Но вот вопросы возврата, отказа при доставке, отказа поставщика, неожиданного отсутствия товара на складе могут ускользнуть от вашего внимания. Лучше продумать все возможные варианты заранее и решить, что из этого будет автоматизироваться, а какие случаи происходят так редко, что лучше их «разгребать» в ручном режиме.

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

Юридическое обеспечение

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

Перечень функций

Документ «Концепция» — это не Техническое задание, поэтому описываются бизнес-функции, верхний уровень. Нет никакого смысла на данном этапе говорить об авторизации и работе с профилем пользователя. Но дать общее представление о функциональности надо обязательно.

Требования к безопасности

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

Выбор варианта реализации системы

Иногда в зависимости от потребностей необходимо определить вид приложения (веб-приложение, нативное), платформу (Windows, Linux), общую архитектуру (один сервер или несколько кластеров), взять ли типовую систему и доработать или вести разработку с нуля. Для этого необходимо сравнить предлагаемые варианты и выбрать наиболее подходящий.

Другие документы предпроектного исследования

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

Заключение

В статье мы очень бегло пробежались по основным разделам предпроектного обследования. Почему бегло? Потому что такое обследование — крайне творческое занятие. Главное, чтобы при прочтении концепции сложилось полное понимание, как это должно работать. А в остальном два документа с результатами исследования могут никак не быть похожими друг на друга. Соответственно и перечень разделов в вашем документе может сильно отличаться от приведенного выше.

Источник

Предпроектные работы для разработки проектной документации

Предпроектные работы – это сбор исходных данных и эскизное проектирование, в результате которых приходит осознание всех параметров и характеристик будущего объекта и формируется точное и подробное Техническое задание. Если нужна разработка проектной документации, то не стоит отказываться и от предпроектных работ.
Любой проект начинается с предварительной подготовки, обсуждений, составления технического задания, тщательного сбора исходных данных, с обоснования планируемого проекта, выезда на площадку будущего строительства — все это предпроектные работы. Тщательная подготовка исключит разработку заведомо не реализуемого проекта и лишние затраты при проектировании и строительстве, поможет всесторонне оценить и осмыслить будущий проект.
В проектно-строительной компании Бау Микс уверены: только грамотное техническое решение на основе правильно разработанной концепции дает наибольшую выгоду в ценовом выражении для клиента. Именно поэтому важно учитывать множество нюансов с самого начала, и это — предпроектные работы.

• Получение заключения по инженерным изысканиям:

— топографическая съемка земельного участка (геодезия); геологические изыскания; гидрологические изыскания; экологические изыскания; охрана окружающей среды.

• Проверка инженерного обеспечения ЗУ, получение технических условий (ТУ) на подключение к инженерным сетям (электричество, водоснабжении и водоотведение, отопление, газ).

• Эскизный проект (ссылка на скачивание файла по эскизному проекту).• Удаление или пересадка зеленых насаждений.

• В случае реконструкции требуется техническое обследование здания и сооружений.

• Получение градостроительного плана.

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

После сбора прохождения данного этапа можно обращаться в проектную компанию на разработку проектной документации. Также возможна разработка проекта с комплексом услуг в области информационного моделирования зданий — BIM проектирование, перевод «стандартной» 2D документации в BIM среду и выполнение трехмерных моделей инженерных изысканий.

!ВАЖНО! Как правило проектная документация разрабатывается в 2 стадии: 1. Стадия П (проект, разработанный для прохождения экспертизы / ПД);

2. Стадия Р (рабочая документация, выполняется на основании “стадии П”).

Двухстадийное проектирование потребуется в случае, если объект капитального строительства:

• относится к объектам массового пребывания граждан;

• является особо опасным, технически сложным или уникальным объектом;

• площадь объекта больше 1500 м²;

• объект выше 3 этажей;

• если требуется установление санитарно-защитных зон на ЗУ.

Если ваш объект не подпадает под данные пункты, то можно сразу переходить к разработке рабочей документации (стадии Р).

Источник

Кому нужно ППО и в чем его ценность

Ведущий системный аналитик AGIMA

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

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

Содержание

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

С их помощью мы должны ответить на ряд вопросов: каковы будут скоуп, структура и функционал продукта? В чем состоят ожидания заказчика? Каковы сроки и стоимость выполнения работ? Какие функции войдут в MVP?

Инструментом, который дает нам ответы на все вопросы, является предпроектное обследование. Для краткости будем дальше использовать стандартное сокращение — ППО.

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

Первые — это представители заказчика: руководители бизнес-юнитов, стейкхолдеры, технические специалисты, специалисты обеспечивающих подразделений, которые в ходе своей работы сталкиваются с заказами на создание или принятием первоначальных этапов работ по созданию ПО.

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

Что такое ППО и как оно выполняется

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

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

Из чего состоят результаты ППО

Разберем более детально типичные артефакты ППО.

Полезно использовать следующую структуру документа:

На наш взгляд, для составления и дальнейшей работы лучше всего подходит табличная форма, где в первой колонке будет раздел или фича, а во второй — функция. Обычно мы делим функции по следующим ролям: пользователь (П), бизнес-пользователь (БП), администратор (А), система (С).

Помимо оценки, декомпозированные таким образом функции позволяют легче собрать use-case конечного пользователя продукта и АРМ внутренних пользователей для размещения их в соответствующем разделе Vision.

Типовые ситуации «входа» в ППО

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

Наш опыт позволяет сгруппировать проекты по степени их готовности к выполнению ППО:

Зачастую, в зависимости от описанных выше позиций заказчиков, дальнейшие взаимоотношения после выполнения ППО складываются по следующим сценариям:

Как улучшить скоуп проекта

Мы считаем, что самым важным результатом ППО является корректное определение скоупа проекта. Редко когда можно сходу его определить, так как полным пониманием не владеет ни одна из сторон.

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

Ценность для заказчика

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

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

Ценность для исполнителя

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

Декомпозиция дает понимание, какая функция приоритетнее и должна быть сделана раньше, а какая — в следующем релизе.

Стоимость проекта детально обоснована до уровня функции определенной роли. Это помогает на последующих этапах, связанных с защитой финансирования и оценкой эффективности реализации.

Ценность для продукта и проекта

По итогам ППО снижаются риски неисполнения, так как проект делится на понятные всем сторонам этапы с соответствующим наполнением.

Подробная оценка длительности работ на основе декомпозиции избавляет участников от «излишнего оптимизма» — недооценки времени на реализацию.

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

Источник

Предпроектное обследование

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

Характеристики процедуры и ее особенности

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

Специалисты, выполняющие исследовательские работы должны обладать профильным образованием, иметь официальные разрешения государственных инстанций и структур системы СРО.

Зачем проводится предпроектное обследование:

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

Основные этапы работ:

Где заказать предпроектное обследование?

Многопрофильная компания «Регион» оказывает частным лицам, строительным и подрядным организациям, инвестиционным и девелоперским фирмам весь комплекс услуг по предварительному обследованию объектов, строительных площадок, незавершенного строительства и инженерных систем. Время проведения предпроектных работ и стоимость эскизного проекта зависит от конструктивной сложности объекта, объема предстоящих работ и их состава, расположения строительной площадки и наличия достоверных данных о фактическом состоянии грунтов, инженерных магистралей и коммуникаций.

Источник

Предпроектное обследование: необходимость или уловка?

Здесь каждая компания принимает решение по-своему: кто-то вообще считает подобное обследование нецелесообразным («ввяжемся в бой, а там посмотрим. »); другие, проводя его в ходе внедрения, не выделяют эту работу в отдельную статью; третьи проводят его как самостоятельный этап работы, однако денег за это не берут; четвертые справедливо считают предпроектное обследование отдельным коммерческим продуктом. Мой опыт как руководителя и консультанта показывает, что предпроектное обследование является необходимой составляющей работ практически любой ИТ-компании, связанной с внедрением систем автоматизации. А от правильной организации и проведения этого этапа порой зависит успех всего проекта.

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

В рамках данной статьи я попытаюсь ответить на поставленные выше вопросы, основываясь как на собственной практике, так и на опыте клиентов, с которыми мне пришлось общаться, внедряя с нуля технологию проведения предпроектного обследования.

Необходимость предпроектного обследования

Приходит изобретатель в комиссию и предлагает новый аппарат для бритья на улице.
«А как же работает ваш аппарат?» — спрашивают его члены комиссии.
«Очень просто, — отвечает изобретатель. — Бросаешь в прорезь монету, засовываешь в аппарат голову, и два лезвия начинают тебя брить».
«Извините, коллега, но ведь у людей форма лица разная!» — делают ему замечание члены комиссии.
«Да, — говорит изобретатель, — но это только до первого бритья. ».

Главная задача любой автоматизации — сохранить уникальные конкурентные преимущества автоматизируемой компании. Нельзя допустить, чтобы, как в этом анекдоте, все компании после автоматизации стали «на одно лицо». Поэтому если мы хотим сохранить уникальные конкурентные преимущества бизнеса заказчика, то при любой модернизации бизнес-процессов обязательно нужно проводить предпроектное обследование.

Конечно, можно произвести глубокий разбор причин, определяющих такую необходимость. Ими могут быть высокая предполагаемая стоимость проекта, потребность в изменении существующих бизнес-процессов при автоматизации, включение в проект работ, объем которых невозможно определить заранее, и т. п. Однако вспомните, как в одной очень поучительной байке полководец прервал доклад генерала о причине поражения:

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

Так что глобально вопрос о необходимости такого рода работ решается довольно легко — их надо проводить, если автоматизируемая компания находится на конкурентном рынке.

Что дает предпроектное обследование заказчику и самой ИТ-компании

В ходе предпроектного обследования заказчик может:

Выгоды предпроектного обследования для ИТ-компании:

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

Основные задачи предпроектного обследования

Очевидно, что следующая по значимости задача предпроектного обследования — выявление уникальных конкурентных преимуществ заказчика. Как показывает практика, порядка 75% бизнес-процессов, используемых заказчиком, совпадают с процессами в аналогичных компаниях той же отрасли, 10% реализуют его уникальные конкурентные преимущества, а оставшиеся 15% являются результатом действия второго закона термодинамики 🙂 (следствием «естественного роста хаоса») и должны быть устранены в ходе проекта. А вот те столь важные для бизнеса конкурентные 10% просто необходимо сохранить при любой автоматизации (естественно, при условии, что эти преимущества можно формализовать). Чаще всего данный вопрос решается конфигурированием системы под заказчика, однако иногда для учета уникальных особенностей бизнеса требуются услуги программистов. Замечу, что здесь речь идет не о заказной разработке, а о внедрении тиражных систем автоматизации.

Понимая, каким образом будут поддержаны конкурентные преимущества заказчика, ИТ-компания сможет оценить необходимость и стоимость доработки продукта, а также понять, какие дополнительные ресурсы могут для этого потребоваться.

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

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

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

Актуальной задачей предпроектного обследования является уточнение окончательного бюджета проекта и сроков его реализации с учетом всех полученных данных. На эти сроки могут влиять самые разнообразные факторы, такие, как готовность управленческого аппарата клиента к участию в проекте, мотивация представителей заказчика и исполнителя, вероятность саботажа со стороны работников автоматизируемых подразделений, возможное увольнение (или, наоборот, прием на работу) ключевого менеджера через некоторое время после начала проекта, недостаточность существующего парка компьютеров и технологической базы для достижения всех целей автоматизации, отсутствие бюджета на закупку необходимого оборудования и многое другое. Поэтому консультант должен детально выяснить все указанные обстоятельства и отразить их в отчете, в том числе и для внутреннего использования. Составление второго — внутреннего — отчета позволит подробно отразить все нюансы взаимоотношений и рекомендации для специалистов отдела внедрения и интеграции.

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

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

Что обычно является результатом предпроектного обследования

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

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

Делать предпроектное обследование бесплатно или брать за него деньги?

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

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

Как обосновать для заказчика эффективность проведения предпроектного обследования

Рассмотрим потенциальные каналы экономии, учет которых может помочь в обосновании необходимости предпроектного обследования.

Отсутствие этапа предпроектного обследования в большинстве случаев приводит к значительному затягиванию сроков реализации проектов и увеличению их стоимости как из-за организационных, так и из-за технических проблем, возникающих в ходе внедрения. Нередко такие проекты вообще заканчиваются полной неудачей. Согласно исследованию Standish Group, почти треть из 2,5 тыс. проанализированных ими ИТ-проектов оказались не просто неуспешными, а вообще не были завершены. В России такие данные получить гораздо сложнее, но уверен, что доля неуспешных внедрений будет не меньше.

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

Источник