Технология IT-консалтинга растет

В России с начала XXI века начался резкий рост IT-рынка вообще и консалтинговых услуг в этой сфере в частности. Все больше и больше консалтинговых компаний входит в рынок консалтинговых услуг, предлагая свое видение и инструментов (программного обеспечения), и технологий производства. И несмотря на кризис до «перегретости» рынка еще далеко, так как спрос значительно опережает предложение. В кризис клиенты стали искать более дешевые предложения, но необходимость в услугах при этом не уменьшилась.

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

Многие же консультанты считают, что достаточно изучить инструментальное обеспечение (Microsoft AX, SAP, ORACLE) и предприятия-клиенты выложат любые деньги за их услуги. Удивительно, но и клиенты отбор консультантов проводят, в первую очередь, исходя из их знаний продукта.

Цель данной статьи – предложить выходы из этой ситуации, помочь консалтинговым компаниям сделать проектные работы более технологичными. Для представления технологии, понятной большинству ее пользователей, необходимо сначала определить понятийный аппарат. И здесь очевидно необходимо использовать исключительно стандартизованные термины. Ведь никто не строит здания без ГОСТ и СНИП. АСУ не менее сложные системы, чем здания, но считается, что они не настолько опасны для жизни, а значит, возможно забыть про стандарты.

О терминологии

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

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

АСУ – целостная организационно-техническая совокупность элементов (информационной инфраструктуры, персонала и регламента) обеспечивающих выполнение автоматизированных информационных процессов, связанных общей функциональностью, информационными потоками и целевым назначением. Это термин, определен в Лит. 1 и не имеет смысла никак по-другому его определять. В иностранных стандартах этот термин определяется как «информационные системы» (ISO 12207). Вообще говоря, иностранные стандарты достаточно вольно трактуют термины, однако термин «информационные системы» в точности повторяет определение АСУ, данное в ГОСТ 34 серии еще в 70-х годах прошлого столетия.

Инфраструктура – взаимосвязанная совокупность средств технического, программного и информационного обеспечения, представленная в виде иерархической послойной структуры объектов, обеспечивающих выполнение всех установленных функций АСУ. В инфраструктуру входят следующие совокупности элементов по слоям: прикладной (приложения), информационный (БД, СУБД), вычислительный (сервера, рабочие станции и т.п.), транспортный (сетевое оборудование, оборудование передачи информации и т.п.), физический (кабельные системы, системы бесперебойного питания, кондиционирования и т.п.).

Система – совокупность сильносвязанных элементов, обладающая минимум четырьмя свойствами:

  • Целостность и членимость – это целостная совокупность целостных элементов, каждый из которых возможно рассмотреть как отдельный элемент;
  • Связность – существенные и устойчивые связи элементов друг с другом превосходят по силе связи этих элементов с другими сущностями, не входящими в данную систему;
  • Организация – энтропия системы меньше суммы энтропий входящих в нее элементов;
  • Интегративность – у системы есть такие качества, которые не присущи ни одному из ее элементов в отдельности (лит. 7).

Составляющие технологии

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

Для консалтинговых компаний методикой является совокупность документов, описывающих:

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

Вообще говоря, стандарты серии CMM требуют на каждом уровне «завершенности процессов», еще около десятка процессов, обеспечивающих процесс производства (проектирования и внедрения). Однако в России эти процессы, как правило, не выделяются в отдельные, а выполняются в составе основных. Например, процесс управления требованиями должен быть определен явно (для определения процесса необходимо определить состав функций/подпроцессов, владельца процесса, входной и выходной потоки, цели и свойства). Так как этот процесс не выделен явно, то любые изменения требований клиента просто вызывают дополнительную оплату или отметаются консультантами/проектировщиками как невозможные. Сразу возникает конфликт, но так как процесс управления требованиями не описан, не определен в договоре или в проектной документации, возникают коллизии и недовольство.

В качестве инструментов используются различные программные приложения от редактора таблиц MS Excel до MS Project и им подобных.

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

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

Методика консалтинга

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

С чего надо начинать при разработке собственной методики?

В первую очередь, надо понять, какой продукт компания производит. Чаще всего консалтинговые компании считают, что они оказывают именно «консалтинговые» услуги. Однако при ближайшем рассмотрении выясняется, что даже при внедрении 1С эти услуги более похожи на «проектные», чем на консалтинговые. Очевидно, что под консалтингом должно пониматься именно консультирование при внедрении программных продуктов, а не составление технического задания (ТЗ) и внедрение системы в соответствии с ним. Конечно, элементы консалтинга все компании вынуждены делать на первых проектных стадиях, так как процессы у клиента не оптимальны вообще или не оптимальны для конкретного программного инструментария. Например, все понимают, что российские компании иногда вынуждены делать бухгалтерские проводки «задним числом». Однако западные продукты типа Microsoft AX, SAP, ORACLE таких вольностей не позволяют: закрытые период – он и есть закрытый. Приходится иногда оказывать клиенту «медвежью услугу», «оптимизируя» его процессы.

Но конечным продуктом все же являются АСУ. Следовательно, результатом такой работы будет именно создаваемая (проектируемая, внедряемая) информационная система. Сделав такой вывод, необходимо найти стандарты, определяющие способы разработки подобных систем. В случае с информационными системами в настоящее время основными действующими являются стандарты ISO 12207, ISO 9001:2008, CMMI и ГОСТ серии 34. Во всех крупных компаниях производителях программного обеспечения существуют собственные методики разработки, как в компании ORACLE, например. (лит. 8).

Во вторую очередь надо выделить стадии (этапы) создания такой системы. Эти стадии также определяются существующими стандартами. Чаще всего это: предпроектная подготовка (продажа), обследование предприятия (определение требований), системное и техническое проектирование, разработка и опытная эксплуатация. Некоторые компании используют термин «дизайн проекта». К сожалению, ни в одном из перечисленных стандартов такого термина не определено. К тому же в «дизайн проекта» складывается вся информация по проектируемой системе: входные/выходные отчеты, алгоритмы, формулы, процессы и т.д. В итоге за самую длительную стадию работ заказчик вынужден заплатить до 70% бюджета проекта, не получив на выходе ничего. В случае же стандартной модели жизненного цикла, заказчик может уже на первой стадии вносить изменения в проектную документацию, новые требования, анализировать прототип системы.

После определения жизненного цикла необходимо определить, какие проектные документы разработчик будет представлять клиенту на согласование. И здесь самый быстрый и простой вариант – использование действующих стандартов. В лит. 3 приводится полный список документации, которая должна разрабатываться при проектировании АСУ. В случае если консалтинговая компания занимается только внедрением программного приложения, большинство документов можно не разрабатывать. Если же компания создает АСУ «под ключ» с поставкой элементов технического обеспечения, тем более имеет смысл ознакомиться с составом и содержанием соответствующих документов из представленных стандартов.

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

На последнем шаге остается разработать процедуры обеспечения качества работ на проектах и его контроля. И здесь можно воспользоваться стандартом ISO 9001:2000.

Конечно, необходимо в любом случае изучить стандарты CMMI, SPACE. Это стандарты, описывающие процессы разработки программного обеспечения. Ведь, как правило, «консалтинговые» компании кроме оптимизации процессов вынуждены заниматься и донастройкой программного инструмента и, почти всегда, дополнительным программированием (кастомизацией). Из этих стандартов надо взять обязательные процессы (хотя бы уровня 3 CMM).

В качестве примера можно привести процесс «управление конфигурацией», без которого ни одна уважающая себя компания не проектирует серьезные системы. Каждый из нас может вспомнить массу примеров из реальных проектов, когда члены команды проектировщика компилировали разные версии модулей, выполняли противоречащие друг другу настройки в разных модулях единой системы и т.д. На обучении я часто привожу пример коммерческого директора одной из торговых сетей российского города-миллионника, которому были во время проектирования системы выданы все права на ее настройку. Он поставил в AXAPTA галочку «распространить на всю группу товаров» и забыл про это. Через неделю он установил наценку на один из сортов колбасы 3% (заканчивались сроки реализации) тогда как средняя наценка по группе была 27%.

Убыток в 25 тысяч американских долларов предложили оплатить консультантам.

Краткое описание стадий жизненного цикла

Предпроектное обследование проводится с целью подготовки договора с логическими рамками работ. За эту стадию отвечает, как правило, коммерческий отдел, который может привлекать консультантов. Так как все процессы в компании должны быть взаимосвязаны, неплохо, чтобы в описании стадии «Предпроектное обследование», были отмечены связи с процессом продаж, а точнее даже с технологией продаж. Также как и любая технология, технология продаж должна быть основана на методике продаж и инструментах (Microsoft CRM и т.п.). Из своей практики могу сказать, что основные проблемы между процессами (подразделениями, отвечающими за эти процессы) возникают в вопросах определения цены услуг. С одной стороны, продавцы получают бонусы за объем продаж, с другой стороны – за сами продажи. Чаще всего все-таки продавцы стараются продать продукт/услугу дешевле, предполагая, что по ходу проекта появится возможность увеличить объем бюджета проекта, при этом они делают продажу. Проектные же отделы (если они технологичны и не только производят качественный продукт, но и заинтересованы в уменьшении его себестоимости) не готовы работать по дешевым расценкам. Это на практике часто приводит не только к срыву сделок, но и к разобщению разных отделов внутри компании-проектировщика. Выход тут только один – формализация отношений, четко проработанные KPI для каждого отдела.

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

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

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

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

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

Опытная эксплуатация описана достаточно подробно и понятно в Лит. 10.

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

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

Обеспечивающие процессы

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

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

Итак, какие же процессы должны быть отражены обязательно в методике проектирования?

Стандарты определяют всю их совокупность:

  • документирование;
  • управление;
  • обеспечение качества;
  • управление конфигурацией;
  • управление требованиями;
  • верификация и валидация;
  • управление несоответствующей продукцией;
  • управление рисками;
  • управление закупками.

Вообще говоря, в крупных компаниях, так или иначе, все эти процессы выполняются, однако для того, чтобы эти процессы были определены, необходимо описать их, то есть определить:

  • владельца процесса;
  • связь с другими процессами;
  • совокупность подпроцессов, функций;
  • входные/выходные потоки;
  • цели процесса.

На практике чрезвычайно редко делаются такие описания, что всегда приводит к коллизиям. Например, одна из крупнейших сетей аптек, исполняя регламентированные государством процессы управления несоответствующей продукцией (просроченные лекарства), всегда снимала такой товар с полок и размещала его в отдельном углу на складе аптеки. Так как аптек было много, а специальный человек не следил за выполнением именно этого процесса, продавцы в зале, грузчики часто передвигали эти коробки или брали их для размещения на полках. Когда же приходили новые люди (текучка была в 2007 году довольно большая), им вообще забывали иногда сказать, где размещается такой товар. В продовольственных сетях происходит то же самое. Каждый из нас встречал подобный товар на полках магазина, однако на практике не всегда менеджер (заведующий) отдела специально выбрасывает на полки просроченный товар – он просто забывает о таком товаре или его подчиненные продавцы не обращают внимания на то, откуда они берут товар для выкладки. С точки зрения автоматизированной системы такие ошибки всегда приводят к пересортице, недостаче и т.п. Исправление этих ошибок возможно только путем инвентаризации, а это – одна из самых дорогих процедур в ритейле. Кстати, всегда можно и на консультантов переложить вину.

Инструмент консалтинга

Мы уже упоминали программные приложения, чаще всего используемые при управлении проектами. Это и MS Excel, Word, MS Project и другие системы подобного назначения.

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

Итак, какова же роль технологии в консалтинге?

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

Проектные риски

Риски, возникающие на проектах внедрения ERP-систем (АСУ), всем известны, это:

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

Использование технологии проектирования позволяет снизить большинство перечисленных рисков и даже исключить некоторые из них.

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

Использованная литература

1. РД 50-680-88 «Автоматизированные системы: Основные положения».

2. ГОСТ 34.601-90 «Автоматизированные системы: Стадии создания».

3. ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем».

4. РД 50-34.698-90 «Автоматизированные системы: Требования к содержанию документов»

5. Г.Н. Калянов «Консалтинг при автоматизации предприятий».

6. ГОСТ 34.602-89 «Информационная технология: Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

7. В.И.Николаев, В.М.Брук «Системотехника: методы и приложения».

8. Oracle Method. Application Implementation Method (AIM) 3.0 Handbook.

9. Oracle Method. Application Implementation Process and Task Reference.

10. ГОСТ 34.603-92 «Виды испытаний автоматизированных систем».

Источник изображения: pixabay.com

Расскажите коллегам:
Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии
Нач. отдела, зам. руководителя, Санкт-Петербург

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

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

CIO, Санкт-Петербург

Интересно, кто является целевой аудиторией данной публикации?
Из всего текста верно описаны только проектные риски, все остальное - для отдела маркетинга (да и там обычно сидят более продвинутые сэйлзы).
А уж ссылки на CMM в РФ - это вообще песня. :|

Нач. отдела, зам. руководителя, Санкт-Петербург
Компании выстроились в очередь к консультантам за ERP-системами, но вот как правильно подойти к внедрению, и все учесть и ничего не упустить, знают единицы.
Ага, а консультанты выстроились в очередь на бирже труда. =) Статья маркетинговая. Консультанты не занимаются продажами ERP непосредственно, смысл к ним за ними стоять? Раздел консультантов на работных сайтах (в разделе IT, разумеется) забит продавцами-консультантами, консультантами по недвижимости, консультантами по бухгалтерскому учёту и т.д. Но не консультантами по ERP, хотя такие вакансии ещё есть. :) У Microsoft в 2009 г провал продаж на ~50%. В 43% IT-компаний на сегодняшний день задерживают з/п. Объём рынка IT-услуг за прошедший год сократился более чем в 2 раза. Так что очень своевременный материал. )
Менеджер, Москва

1. Самое главное не дали определения консалтингу, что же понимаем под этим видом деятельности. В начале вскользь упоминалось, что на самом деле под консалтингом часто понимают разработку или внедрение ПО, а это принципиально разные задачи. И далее уже речь и шла о том, как организовать как раз разработку.
А разница между разработкой, внедрением и консалтингом, на самом деле, принципиальна. Всё начинается с постановоки задачи, если для разработчика ставится задача ''сделайте нам систему у которой на входе будет 1, 2, 3, а на выходе 6, 5, 4'', то для внедрения ''тиражируемого'' ПО задача должна звучать как: ''установите нам данное ПО, настройте его под нас, запустите, научите какие кнопки жать'', если же Заказчику действительно требуется консалтинг, то задача должна ставиться иначе: ''у нас есть сложности, как нам их обойти, порекомендуйте''.
На практике конечно же всё перемешивается... Все поголовно именуют себя консультантами, хотя ничего большего чем настройку системы под запросы Заказчика не делают и даже не утруждают себя попытками объяснить Заказчику, что это ему может быть не нужно, не удобно и вообще выбранный продукт для этого не подходит. Да и сами Заказчики часто с недоумением относятся к ситуации, что нельзя или не нужно что-то делать, ведь он же заплатил деньги - за них должны удовлетворяться все его капризы...
Как однажды сказал мне один из Заказчиков: ''Да я еле сдержался, чтобы тебе по морде не дать, когда ты сказал, что я должен был ТЗ читать...''.

2. Отчасти многие проблемы возникают, от того, что стадия пресейла идёт перед стадией обследования. Зачастую на обследовании выясняется, что Заказчику нужно собственно не то, что ему продали, да и продукт ему этот совсем не подходит, и вообще у него уже есть система, функциональность которой не может быть перекрыта предлагаемой, а что делать - договор заключен, деньги в бюджет заложены, лицензии уже в закупке... Вот тут и начинается вместо КОНСАЛТИНГА, вылепливание из ТИРАЖИРУЕМОГО продукта, УНИКАЛЬНОЙ системы...

Владимир Зонзов +10253 Владимир Зонзов Директор по производству, Украина
Василевский Сергей пишет: Вот бы кто-нибудь еще написал статью для заказчиков ИТ-консалтинга, чтобы они перестали подменять цели средствами - тогда обе стороны ИТ-консалтинга, думаю, работали бы максимально результативно.
Такая статья нужна. А то часто заказчик, вместо изложения проблемы, излагает своё ''общее'' представление о способе её решения.
Knowledge manager, Украина
Владимир Зонзов пишет: Такая статья нужна.
Какая же тут может быть статья? Информационные технологии ведают инструментами сбора, передачи и хранения информации. А информация содержится в документах. А состав и содержание документов - епархия тех, кто СТРОИТ бизнес, а не тех, кто ПОМОГАЕТ его оптимизировать.
Владимир Зонзов пишет: ...А то часто заказчик, вместо изложения проблемы, излагает своё ''общее'' представление о способе её решения.
Вы безмерно добры, Владимир. Заказчик НЕ МОЖЕТ изложить то, чего не понимает. Поэтому он и ведет себя, как студент. Излагает то, что знает, а не то, что спрашивают.
Консультант, Москва
Валерий Корчевский пишет: Заказчик НЕ МОЖЕТ изложить то, чего не понимает. Поэтому он и ведет себя, как студент. Излагает то, что знает, а не то, что спрашивают.
Но увы, подчас заказчик (ЛПР) считает, что его мнение о СПОСОБЕ РЕШЕНИЯ задачи и есть более правильное, нежели у консультанта (не важно - штатного ли спеца или нанятого), а консультант - лишь технический исполнитель воли (''гениальных задумок'') заказчика. И ведёт себя заказчик уже не как студент, а как иезуит-инквизитор: ''Таки она круглая и вертится? Ересь, на костёр еретика!'' (и дабы не попасть на ''костёр'' - т.е. потерять контракт/работу - многие гнутся под клиента. Киньте в меня камень, если это не так :)) И не важно, включается ли в проект бизнес-консультирование (явно или неявно), или речь только о внедрении отдельного ИТ-инструмента для реализации конкретной задачи/функции. Что до статьи - мне она понравилась хотя бы тем, что я на собственной шкуре убедился в важности и правильности советских ГОСТ-34.х (особенно - 601, этапы и стадии создания), за которые ратует автор.
Юрий Максименко Юрий Максименко CIO, Украина
Борис Зверев пишет: Что до статьи - мне она понравилась хотя бы тем, что я на собственной шкуре убедился в важности и правильности советских ГОСТ-34.х (особенно - 601, этапы и стадии создания), за которые ратует автор.
Раз убедились в их правильности -- значит, не проектировали достаточно сложную систему для предприятия. Значит, это было что-то тривиальное. Типа складского учёта. А вот я на своей шкуре убедился в правоте Фредерика Брукса: «Правда заключается в том, что клиенты не знают, чего хотят. Обычно они не знают, на какие вопросы нужно дать ответ, и почти никогда не задумываются над задачей настолько детально, как это нужно указать в спецификации... Я пойду дальше и стану утверждать, что на практике клиенты, даже вместе с инженерами-программистами, не в состоянии указать полно, строго и корректно точные требования к современному программному продукту, прежде чем будут созданы и опробованы какие-либо версии продукта, спецификации к которому они составляют» (Фредерик Брукс «Мифический человеко-месяц, или как создаются программные системы», глава 16). У меня было четыре серьёзных внедрения (я сейчас не беру свои работы типа программы печати справок о составе семьи для мэрии и т.п.). И во всех этих случаях основные корректировки проходили уже на этапе внедрения. Зато работали системы потом много лет (мой рекорд -- десятилетие с поддержкой и семь лет без поддержки).
Knowledge manager, Украина
Юрий Максименко пишет:... «Правда заключается в том, что клиенты не знают, чего хотят. ...
Не вижу в этом ничего страшного, не может человек знать всё. Неприятно, когда Заказчик НАСТАИВАЕТ на своей правоте, не имея никакого представления о деталях предполагаемого проекта. Мне легче. Я могу отказаться от такого заказа.
Юрий Максименко Юрий Максименко CIO, Украина
Валерий Корчевский пишет: Неприятно, когда Заказчик НАСТАИВАЕТ на своей правоте, не имея никакого представления о деталях предполагаемого проекта.
А лично я не берусь за дело, если не чувствую, что мы с Заказчиком одинаково представляем смысл проекта. То есть я представляю себе, что я -- это он, сажусь в его кресло и начинаю думать -- а вот на хрена мне эта автоматизация. Что изменится в моей жизни? И результаты сверяю с мыслями предполагаемого заказчика. Если нет совпадения -- лучше уйти сразу.
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Каждый пятый россиянин не получал повышение уже более 5 лет

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

70% россиян знают ценности своей компании

Женщины чаще, чем мужчины, отмечают, что знают о ценностях своей компании.

Средняя зарплата россиян превысила 85 тысяч рублей

За год ее размер увеличился на 18%.

X5 Group автоматизирует 30% рабочих процессов, выполняемых человеком

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