Проектирование функционала ERP систем

Проектирование функционала ERP систем

Предлагаю на обсуждение участников конференции статью с описанием методики проектирования функционала ИС ERP класса. Статья доступна по ссылке http://piter-consult.ru/home/Articles/it-managment-articles/Consulting-stage-information-system-adjustment.html. Буду благодарен за конструктивные замечания

227
Комментарии (4)
  • 30 мая 2009 в 20:35 • #
    Магомед Тутаев

    Прочитал в статье:
    Если этот вопрос будет отдан на откуп программисту, заказчик может быть неприятно удивлён результатом в тот момент, когда обязательства внедренцев по этому вопросу будут уже выполнены. Активное участие заказчика в определении форматов является залогом получения результата в действительно «удобном для анализа виде».

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

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

  • 1 июня 2009 в 11:07 • #
    Сергей Кручинецкий

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

  • 1 июня 2009 в 11:47 • #
    Магомед Тутаев

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

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

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

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

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

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

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

  • 1 июня 2009 в 14:40 • #
    Сергей Кручинецкий

    Статья адресована именно многоуважаемому Заказчику. Внедренцы, имеющие консалтинговый ресурс, сами хорошо знают, как проектировать функционал. Не имеющие - по идее должны подряжать консультанта (см., например, проект 1С:Консалтинг), но чаще просто подгоняют нужды заказчика под типовой функционал. В таком случае эта статья тоже ни к чему.
    Варианты границы между работой консультанта и заказчика над ФУНКЦИОНАЛЬНЫМ проектом лежат между двумя крайними случаями:
    1. Заказчик может иметь собственный консалтинговый ресурс и в состоянии самостоятельно разработать функциональный проект.
    2. Этот крайний случай описан в статье: "...на вход внедрения ИС должны быть переданы исходные данные, а именно, стратегия компании".
    Конкретный вариант границы зависит от степени проработки системы управления заказчика.
    Вопросы проектирования ИС, выходящие за рамки компетенции управленческого консультанта, можно найти, например, в типовом ТЗ на проектирование ИС. На эти темы можно написать не одну статью, но это уже не моя компетенция :-)


Выберите из списка
2014
2014
2013
2012
2011
2010
2009