25 апреля 2013 в 17:28

Оцените риски проекта

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

599
Комментарии (17)
  • 26 апреля 2013 в 09:22 • #
    Сергей Новиков

    Михаил, риски как всегда будут очень высокими, в случае если со стороны Компании (холдинга) не будет руководителя данного проекта который:
    - понимает специфику бизнеса и стратегические цели Компании
    - знает особенности работы Компании и хорошо понимает её структуру
    - имеет компетенции в области маркетинга и менеджмента
    - представляет бизнес-процессы Компании (сквозные бизнес-процессы!) на уровне технолога
    - понимает возможности современных информационных технологий

    Если со стороны компании нет четко сформулированных требований и понимания что, как и за счет чего может быть оптимизировано (не путать с автоматизацией! :) ), то успех подобного мероприятия примерно как подкидывание монетки, это самый оптимистичный прогноз :)

    И как обычно врятли будет проведена реальная оценка эффективности данного проекта и уж тем более официально опубликована данная информация :)

  • 26 апреля 2013 в 10:40 • #
    Михаил Тарасов

    Что сможет сделать хороший руководитель проекта, если у исполнителя не хватит компетенций? Поскорее выйти из проекта?

    Сможем ли мы когда-нибудь что-то узнать об этом проекте? Вполне, из прессы, лет через 10. :-)

    Вот недавно про Аэрофлот написали, что лет 10 они не могли внедрить SAP, а потом за 1,5 года с новым ИТ-директором раз, и внедрили!

  • 26 апреля 2013 в 11:10 • #
    Сергей Новиков

    Михаил, нужно разделять данную задачу на несколько этапов.

    1. Это создание требований на систему для поддержки и оптимизации бизнес-процессов Компании исходя из интересов и потребностей бизнеса.
    2. Создание системы (или доработка в случае коробочного варианта :) )
    3. Процесс внедрения информационной системы.

    95% неудач подобных проектов начинается как раз на первом стратегически важном этапе, как итог последующие этапы уже априори не могут получиться "удачными" с точки зрения бизнеса - Компании заказчика.

    Да, во втором и третьем этапах то же достаточно сложностей, но больше технологических.
    И опять же, как показывает практика за счет консультантов часто пытаются решить и первый этап, фактически получается так - пусть придут консультанты мы им заплатим, и они всё за нас сделают как надо и внедрят «лучшие практики» :), "ан нет" что-то не срастается! :)

    Естественно, что для реализации 2-3 этапов необходимы то же серьезные компетенции в области разработки ПО и информационных технологий, но если изначально фундамент будет заложен неправильно, то результат будет предсказуемым!

  • 26 апреля 2013 в 11:44 • #
    Михаил Тарасов

    Это известные вещи, но нет ответа на мой вопрос. Мне было бы интересно узнать, как заказчику бороться с риском того, что исполнитель может не справится с проектом, не имея опыта работы с проектом моего масштаба.

  • 26 апреля 2013 в 12:17 • #
    Сергей Новиков

    Оплата по результату проекта! :))
    Конечно если мы не говорим о подобных проектах в целях "откатинга" :)

  • 26 апреля 2013 в 13:07 • #
    Михаил Тарасов

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

  • 26 апреля 2013 в 13:37 • #
    Сергей Новиков

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

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

    Нерешаемых задач не бывает, было бы желание! :)

    С уважением,

  • 26 апреля 2013 в 10:41 • #
    Андрей Потапов

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

  • 26 апреля 2013 в 10:46 • #
    Михаил Тарасов

    Ну эта статья абсолютно рекламная. Но можно поизучать BearingPoint - что вообще они предлагают.

  • 26 апреля 2013 в 13:07 • #
    Андрей Потапов

    c сайта: http://www.vneshtorg.biz/index.php/russia/873-b0027-bearing-point.html
    "
    Решения для Коммерческого и Государственного секторов
    Трансформация бизнеса и реализация бизнес-стратегии
    Управление рисками, соответствие требованиям регулирующих органов, Управление информацией, Трансформация и стратегия развития ИТ, Решения на базе SAP, Решения на базе Oracle, Отраслевые решения.

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

    SAP и Oracle - это хорошие программные продукты. Но дорогие... И я не нашел отечественного продукта у них. А знчит, что они будут подгонять SAP под наше законодательтво - это всегда проблемы.

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

  • 26 апреля 2013 в 16:20 • #
    Денис Чернов

    провал вот и все

  • 26 апреля 2013 в 17:41 • #
    Наталья Лопатина

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

  • 27 апреля 2013 в 20:34 • #
    Михаил Тарасов

    И я о том же. Только предлагаю обсудить, как бороться с риском отсутствия опыта работы с масштабным проектом.

  • 27 апреля 2013 в 21:15 • #
    Наталья Лопатина

    Отсутствие опыта - это не риск, а факт. Правда, даже если говорят, что опыт есть, даже если есть доказательства - это еще не говорит об успешности проекта, и о том, что они понимают что делают - ошибаться можно множество раз. Как бороться? как обычно - следить за каждым шагом. Звонить каждую неделю узнавать что сделали. Разбивать акты на минимальные этапы, чтобы отчитались по каждому по полной... и ответили также по полной и может даже исправили по полной... пару раз. Это же Айти... Они уверены в том, что все знают лучше... При этом конечно они все хорошо знают, если им все подробно объяснить. Единственный способ бороться - точно знать, что нужно, как должен выглядеть проект и как работать, какие данные должны быть, как они будут зависеть друг от друга, какие отчеты, какие проверки данных. И здесь уже не важно - есть опыт у разработчика или нет. Для программиста главное - знать язык. То что он сделает зависит от того, насколько конкретно заказчик представляет себе, что он хочет. Если Заказчик этого не знает - а это как раз и есть главный риск масштабного проекта, - то он и получит белиберду, которую по двадцать раз придется переделывать.

  • 29 апреля 2013 в 10:49 • #
    Михаил Тарасов

    Я бы всё же сказал, что отсутствие достаточного опыта - это факт, который является риском, так как проблема с опытом может привести к провалу, а может и нет. Затем, этим риском можно управлять - например, так, как пишете Вы.

  • 27 апреля 2013 в 21:20 • #
    Наталья Лопатина

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

  • 29 апреля 2013 в 10:58 • #
    Михаил Тарасов

    Но вот если представить: был маленький проект, всё сделали правильно, ТЗ написали, всё всем растолковали. А теперь вот большой проект. И опять: собрались, написали, растолковали... Не верю, что всё пойдёт тогда гладко. Ну вот, например, хотя-бы подумать о достаточности человеческих ресурсов. И вот ещё известно, что на небольших объёмах данных система работает без проблем, а при их увеличении - могут появиться проблемы...


Выберите из списка
2018
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008