Управление проектами внедрения 1С:ERP

21.06.18

Бизнес-анализ

Тема статьи - «Управление проектами автоматизации 1С:ERP». В этой фразе хотелось бы поставить ударение на 1С:ERP. Почему? - Потому что 1С:ERP – это достаточно сложный комплексный продукт. - Проекты, которые мы делаем, зачастую охватывают все отделы и службы предприятия. - Здесь, в отличие от того же УПП, требования немного меняются – речь идет уже не об учете, а о планировании, об управлении ресурсами, что само по себе является более сложной темой. Об этом я и постараюсь рассказать.

Проект еще не начался. Этап «пресейла»

Свое рассмотрение вопроса управления проектами 1С:ERP я начну с этапа пресейла.

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

Вопрос пресейла критичен и когда вы выступаете со стороны франчайзи, и когда вы работаете в штате компании. Это – такой этап, когда вы готовитесь к началу проекта и обосновываете этот проект для заказчика (или для своего директора). Поэтому этап пресейла есть всегда. На этом этапе закладывается как раз тот фундамент, который позволит в дальнейшем говорить о том, будет ли проект успешным.

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

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

Что нужно на этапе пресейла заказчику?

  • Во-первых, сейчас полностью перестала продаваться отдельная учетная составляющая – учет и технические знания. На слайде я написал, что технари больше не продаются. Это сейчас особенно отчетливо видно в случае комплексных проектов. Что продается?
    • Продаются бизнес-навыки того человека, который себя позиционирует как руководитель проекта.
    • Продается его понимание бизнеса.
  • Когда мы говорим о больших проектах, ситуация выглядит следующим образом – у собственника бизнеса ( генерального директора, того, кто будет инвестировать деньги) на одной чаше весов находится ваш проект стоимостью 20 млн рублей, а на другой чаше весов – новое оборудование, которое он может приобрести за эти же деньги.
    • Ему понятно, что при покупке оборудования он сможет расширить производимый ассортимент товаров, снизить затраты на производство. Ему понятна та доходная часть, которая будет у него после того, как он запустит это оборудование в работу.
    • А в случае проекта автоматизации – непонятно, каким образом он отобьет эти 20 миллионов и как эти инвестиции позволят ему что-то сэкономить (увеличить объемы продаж, оборачиваемость товаров, снизить какие-нибудь запасы и т.д.). Это все человеку нужно рассказать и объяснить.

При продаже проекта 50% вашего успеха – это убедить заказчика в том, что он получит бизнес-выгоды. Например, вы говорите: «заплатите нам сейчас 20 миллионов рублей, а через год вы получите экономию в 50 миллионов».

  • Следующие 50% от продажи будут зависеть от того, сможете ли вы заказчику доказать, что он через год реально получит 50 миллионов экономии. Это уже не маркетинг. Люди, которые являются заказчиками таких проектов, хорошо разбираются в бизнесе. Поэтому вы должны:
    • Провести анализ:
      • Финансового состояния предприятия;
      • Того, как управляются запасы;
      • Того, как работает система планирования.
    • На основании этих данных сформировать предложения по улучшению ситуации.
    • И донести свои выводы до заказчика на простом, человеческом пользовательском языке.
  • Важна консалтинговая составляющая всего этого процесса. Если вы умеете проводить консалтинг, вы продадите такой большой проект. Иначе вас просто не услышат, какой бы хороший технарь вы ни были. Люди просто не понимают, когда им начинают рассказывать о том, что у них будет хорошая красивая система и пр. Все это сразу отметается. За такие деньги коробку никто не покупает.

Это было о том, что нужно заказчику.

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

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

Переход на новую систему – это всегда небольшая (а иногда и большая) революция. Люди будут прибегать к вам с безумным видом и кричать о том, что раньше все было лучше, а теперь все сломалось и ваша система негодная. Только если у вас будет светлая идея о том, что ваш проект сможет что-то серьезно улучшить в бизнесе, вы сумеете довести этот проект до результата. У нас есть несколько проектов, которые были успешны именно в таком аспекте. Они были нацелены как раз на то, чтобы руководитель проекта изначально нашел эту бизнес-составляющую и всячески ее продвигал и продавал.

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

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

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

На таких «безнадежных» проектах надо просто сразу понимать, чего вы хотите:

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

Этап 0. Организуем процесс работ

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

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

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

До начала проекта нужно сделать очень многое:

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

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

У меня есть несколько советов, которые могут быть достаточно важными – по крайней мере, для меня они были важными.

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

Если говорить о работе на территории заказчика, проверяйте, как люди обустроены у заказчика:

  • Насколько у них хорошие рабочие места;
  • Есть ли у них техника;
  • Есть ли у них нормальный доступ в интернет;
  • Удобная ли у них мебель;
  • И все прочее.

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

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

Этап 1. Проектирование системы

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

Мы все начинали с классического подхода, когда пишется некое ТЗ – документ, в котором перечислены технические требования и к ним написано какое-то техническое решение. Как показывает практика, такое ТЗ – ни богу, ни людям. И пользователи его не понимают, и для программистов оно недостаточно подробное, чтобы что-то по нему начать программировать.

Сейчас мы на этапе проектирования никакие ТЗ на наших проектах не пишем. Что же мы делаем? Результатом этапа проектирования являются два документа, два объекта:

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

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

Что дает этот «Концептуальный проект»? Он преследует две цели:

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

Поэтому концептуальный проект пишется на пользовательском языке максимально понятно.

Здесь я привел пример оглавления концептуального проекта.

  • Сначала идет описание предмета автоматизации;
  • Потом описание по всем процессам, которые протекают;
  • Фиксируется потребность в доработках;
  • И описывается план переноса данных.

Это такой всеобъемлющий документ, в котором:

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

Этап 2. Доработка типовой системы

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

На этапе доработок у нас уже в любом случае появляется техническое задание (ТЗ):

  • ТЗ пишет консультант;
  • В соответствии с этим ТЗ работает программист.
  • И потом, когда программист закончил работу, консультант принимает работу программиста.

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

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

Максимально доступно, максимально понятно для того, чтобы потом, при сдаче этой работы пользователям, можно было опереться на исходный сценарий приемки, который пользователь подписал, и сказать: «Смотрите, вы хотели, чтобы система так работала – она так работает. Если есть какие-то замечания, давайте договариваться».

На слайде приведен пример сценария приемки. Здесь:

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

Этап 3. Обучаем сотрудников

Следующий этап – это обучение сотрудников.

Когда-то достаточно давно, в 2004 году, я делал свой первый большой проект. Мы на этом проекте проводили обучение пользователей, они кивали, говорили – да, все понятно, хорошо, поехали. И в тот день, когда началась опытно-промышленная эксплуатация, я пришел на работу минут на 5 пораньше, в галстучке, с новой записной книжкой. Я думал, что это день моего триумфа – новая система запускается в работу.

Система запустилась, но оказалось, что все не работает: пользователи не знают, как вносить документы; логисты не знают, как доставлять товар; производственники не знают, как фиксировать факт отгрузки. Все пошло «комом» – этот ком катился дня три. Домой я не ездил, жил на работе, как рассказывали очевидцы, воровал колбасу с производства. Не суть важно. Важно, что после этого я понял одно – пользователи на этапе обучения не обучаются.

Здесь есть два варианта:

  • Первый – это выбросить этап обучения вообще и перейти сразу к следующему этапу.
  • А второй вариант – это то, что я сейчас использую.

Я на этапе обучения провожу расширенное тестирование функциональной модели.

  • У меня в программе обучения прописано, что пользователи должны повторять те действия, которые были сделаны в функциональной модели.
  • Что это дает? Когда я в таком расширенном составе тестирую функциональную модель, зачастую всплывают те или иные моменты, которые забыли описать на этапе согласования функциональной модели. Все мы люди, все мы что-то забываем и даже если там были какие-то продвинутые пользователи – они могли забыть какую-то исключительную ситуацию, с которой работает тетя Маша. И тут как раз тетя Маша и говорит: «А что с моим-то делать?». В результате у нас появляется возможность доработать систему, не переходя на этап опытной эксплуатации.
  • Какая у меня здесь задача? Что я говорю всем пользователям? Вы должны удостовериться, что сможете работать в системе. Через месяц начнется опытно-промышленная эксплуатация, деваться вам будет некуда, поэтому проделайте все те операции, которые вы должны будете выполнять в своей ежедневной деятельности, убедитесь, что вас здесь все устраивает. Я это не словами говорю, это написано в программе обучения.

Этап 4. Загрузка начальных данных

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

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

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

Этап 5. Опытно-промышленная эксплуатация

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

По моей оценке, на каждые 20 пользователей нужно иметь одного консультанта. Если у вас 100 рабочих мест, которые нужно запустить на этапе опытно-промышленной эксплуатации, значит, в первый месяц промышленной эксплуатации у вас должно быть 5 консультантов. Если 200 – значит, 10 консультантов.

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

Если клиент сложный, то консультантов нужно больше. Сложный клиент – это:

  • Немотивированный клиент, который не хочет переходить на новую систему;
  • Пожилые люди.

Мы занимаемся проектами ОПК (оборонка), и там достаточно много предприятий, где работают люди в возрасте 60-70 лет. Они там «живут» еще со времен Советского Союза. С такими людьми приходится проводить достаточно много времени. Им нужно рассказывать, как пользоваться компьютером, мышкой и всем прочим.

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

Если вы директор по ИТ (или начальник отдела ИТ) и у вас начинается опытно-промышленная эксплуатация:

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

Второй важный момент с опытно-промышленной эксплуатацией – у вас обязательно должна быть система управления инцидентами. Я пользуюсь Redmine. Все обращения, которые приходят от пользователей, всегда регистрируются у меня в системе.

  • Это делают и сами пользователи – в Redmine есть компоненты, которые позволяют автоматизировать создание инцидентов через электронную почту.
  • И консультанты у меня в обязательном порядке все обращения вносят в систему.

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

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

И вы уже с этими конкретными проблемами начинаете работать:

  • Инициируете задачи на изменение функциональности;
  • Решаете вопрос увеличения бюджета;
  • Или просто исправляете какую-то ошибку, если это ваша ошибка.

Без системы управления инцидентами в больших проектах делать нечего. Я на системе управления инцидентами «вытянул» два проекта – просто внедрил на предприятии систему, куда люди стали регистрировать ошибки и сразу стало понятно, что это просто пользователи расслабились, не хотели делать то, что им говорили.

Роли сотрудников на проекте

Немного лирики. Что я требую от своей команды и от самого себя на проекте?

  • Руководитель проекта – это в первую очередь организатор проекта. Я пришел в руководители из программистов, для меня зона комфорта – это конфигуратор. Но если я сажусь в конфигуратор и начинаю что-то писать, значит, мой проект уже живет своей жизнью, а я зашел в свою «нору» и там сижу. Этого допускать нельзя, потому что вы, как организатор, должны в обязательном порядке процессом управлять и организовывать его. А если вы начнете писать код, то проектом будет управлять кто-то другой.
  • Что я пытаюсь донести до консультантов? Очень многие консультанты «болеют» следующим – они говорят, что «пользователи дураки». Тут у меня аргумент всегда такой – если пользователи дураки, тебя-то, умного, зачем сюда взяли? Чтобы ты людей научил. Учи людей. Твоя задача – выйти за забор «пользователи дураки» и научить их работать с системой. Нужно донести до консультантов, что это – та работа, для которой их и взяли.
  • Про программистов – у нас программисты всегда работают в «черном ящике». Им консультанты задачу поставили и они над этой задачей работают. В такой ситуации у человека очень высок риск потери внутренней мотивации. Он не понимает – то ли он делает, или не то? Хорошо ли это, или плохо? Чтобы поддерживать у программиста определенный уровень внутренней мотивации, ему необходима обратная связь, особенно, когда он работает через консультанта. Ему нужно говорить, что то, что он делает – это пользователям нужно, это у пользователей работает. Если вы не будете им этого говорить, программисты у вас начнут косячить, и вы их просто начнете терять – это из практики.

 

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.

 

Приглашаем на конференции Инфостарта 2025 года

INFOSTART TEAMLEAD EVENT

Не только для разработчиков, но и для руководителей отделов разработки, тимлидов и ИТ-директоров.
Место: Москва
Даты: 24-25 февраля 2025 г.

Подробнее

INFOSTART A&PM EVENT (Анализ & Управление проектами)

Практическая конференция для аналитиков и руководителей проектов 1С.
Место: Санкт-Петербург
Даты: 29-31 мая 2025 г.

Подробнее


См. также

Внедрение изменений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

Мы провели опрос заказчиков с целью определить степень удовлетворенности внедрением 1С: ERP. Опрос проводился по случайной выборке из списка внедренных решений на сайте 1С. Обработали 121 интервью от 97 компаний. Из выборки мы исключали "показательные внедрения" и крупнейшие холдинги, старались получить срез по "средним" массовым заказчикам. Статья будет интересна сотрудникам отделов продаж и отделов качества фирм, внедряющих 1С, потенциальным заказчикам и всем, кто интересуется статистикой внедрения 1С: ERP. Текст статьи довольно большой, в некоторой степени наукообразный.

16.10.2024    1085    0    Soliton    6    

7

Agile Внедрение изменений Бесплатно (free)

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

13.09.2024    2401    0    glebushka    3    

8

Анализ предметной области Анализ бизнес-процессов Работа с заинтересованными сторонами Бесплатно (free)

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

02.09.2024    1115    0    user1669221    2    

7

Внедрение изменений Бесплатно (free)

Когда при внедрении систем 1С всплывает слово «ГОСТ» – практически всегда речь идёт о документе «Техническое задание». И у большинства внедренцев падает настроение, как только им говорят, что надо «написать ТЗ по ГОСТу». Но опытные кулинары знают, как готовить это блюдо так, чтобы оно оставило после себя приятное послевкусие, а не горькое разочарование. О собственных рецептах приготовления документации по ГОСТу пойдет речь в статье.

21.08.2024    2646    53    Laya    3    

21

Анализ предметной области Анализ потребностей и поиск решений Бизнес-аналитик Руководитель проекта Управленческий учет Бесплатно (free)

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

19.08.2024    1467    0    SergeyN    0    

6

Внедрение изменений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

19.08.2024    9539    0    vladshelshel    7    

4

Оптимизация бизнес-процессов Взгляд со стороны Заказчика Внедрение изменений Платформа 1С v8.3 Бесплатно (free)

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

13.08.2024    996    0    avermakov1986    5    

6

Внедрение изменений Бесплатно (free)

Зачастую, если мы пытаемся оценить прямой эффект от внедрения систем 1С, он отрицательный, потому что на внедрение и поддержку ИС надо тратить деньги (часто – очень большие), а даёт она на выходе только информацию. Однако, есть и косвенный эффект, который может быть значительно более существенным для бизнеса. Сама по себе информация о том, что происходит в компании, ничего не экономит. Экономия достигается за счёт управленческих решений и инструментов управления, которые строятся на получаемом поле данных. Расскажем о том, как с помощью автоматизации получить информацию для принятия решений и повысить эффективность бизнеса.

30.07.2024    978    0    MichaelMontrel    2    

6
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Steelvan 306 22.06.18 11:06 Сейчас в теме
пресейл = предпродажа, дальше просто перестал читать и поставил минус
Designer1C; kild; +2 2 Ответить
2. user774630 22.06.18 11:51 Сейчас в теме
(1) а как вы infostart в браузере набираете? Не корёжит?
DenisF8; andironenko; +2 1 Ответить
4. Steelvan 306 23.06.18 17:35 Сейчас в теме
(2) Вы путаете теплое с зеленым.

Для англицизма "пресейл" есть куда более русское слово "предпродажа".

Использование англицизмов называется "Превращение великого и могучего в русско-английский суржик".
Если вам сложно это понять на текущем уровне вашего развития, то попробуйте вернуться к этому через несколько годиков (предложение актуально, если вам до 30).
Designer1C; kild; Yakud3a; +3 2 Ответить
5. andironenko 798 23.06.18 19:00 Сейчас в теме
(4) а что это за хрень у вас в нике "steelvan"?
Tushcan; PowerBoy; +2 Ответить
10. shuhard 24.06.18 10:35 Сейчас в теме
(4)
Использование англицизмов называется "Превращение великого и могучего в русско-английский суржик".

абсурдность данного утверждения в топике по 1С:ERP самоочевидна
7. andironenko 798 23.06.18 19:06 Сейчас в теме
3. genayo 22.06.18 11:58 Сейчас в теме
А кто выполняет роль аналитиков? Консультанты?
6. andironenko 798 23.06.18 19:05 Сейчас в теме
(3) у нас нет специально выделенных аналитиков. Это может быть консультант, может быть архитектор, может быть РП. По сути задача аналитика - это собрать требования, интерпретировать их должным образом и наложить на функциональную модель конфигурации, которая внедряется. Тут все зависит от того у кого есть компетенции в предмете - тот и становится аналитиком.
8. genayo 23.06.18 19:11 Сейчас в теме
(6) Если консультант не имеет навыков аналитика, то он может не увидеть в процессе внедрения/опытной эксплуатации узких мест и возможных улучшений, ведь невозможно все предусмотреть на 100% на этапе сбора требований.
9. andironenko 798 23.06.18 19:20 Сейчас в теме
(8) такая проблема есть, но мы её сейчас решаем не за счёт выделения аналитиков, а за счёт общего повышения квалификации персонала - внутри Раздолья появилась своя бизнес-школа - один из курсов из нее, я, кстати, недавно читал в учебном центре #1 1С - автоматизация пищевки на 1С:ERP. Таких курсов несколько, количество расширяется.
Мы сделали ставку на знание отраслевой специфики - то есть не какие-то общие принципы анализа, а понимание того как что работает в подобном предприятии - что можно делать, а что нет. Тогда люди имеют уже набор готовых шаблонных решени и просто сверяют из с конкретной ситуацией.
11. gendal 10 27.06.18 23:39 Сейчас в теме
"Очень многие консультанты «болеют» следующим – они говорят, что «пользователи дураки"...

Что это за быдловатые консультанты у вас? Если "консультант" не умеет общаться с людьми - завалит все дело. На этапе внедрения, особенно если работала другая система ранее, которая "вылизана" и под любой чих пользователя есть отчет, работа в новой системе вызывает сравнение и сопротивление. Какие-то вещи банально не удобно реализованы и пользователи отказываются так работать. Тут нужно быть дипломатом, тупым продавливанием ничего не выйдет. А любое серьезное внедрение - это десятки тысяч сказанных слов и человеко-часов плотного общения с пользователями.
12. andironenko 798 01.07.18 11:46 Сейчас в теме
(11) Ну прям вот "дураки" никто конечно не говорит - но достаточно часто присутствует определенное ложное чувство собственного превосходства над пользователем. Которое ведет консультанта по неправильной дороге и приводит к конфликтам.
13. kuril 57 31.07.18 13:41 Сейчас в теме
Хороший и объемный материал, Андрей! Спасибо

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

Есть методика разработки и внедрения информационных систем - ГОСТ 34
Если соединить все - предпродажу -> проект -> дальнейшие продажи
то я бы описал это следующим образом:

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

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

2. Самое лучшее что я видел по ведению (не мелких) проектов ГОСТ 34 - там есть все
0) устав проекта - на мой взгляд - нужно на очень крупных (over 10000 человек) предприятиях при тотальных проектах. меньше - мертвый документ.
а) приказ о рабочей группе
б) тех.требования + подпись
в) эскизный проект - как можно скорее - это такой MVP будущей системы.
г) программа и методика испытаний (ПМИ) + подпись
д) программа обучения->приказ об обучении->обучение -> акт
е) тестовая эксплуатация (ТЭ) -> доработка (scrum)
ж) опытная эксплуатация (ОЭ) -> приемка -> доработка (scrum) ->Акт
з) промышленная эксплуатация (ПЭ) -> акт

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

Считаю самым важным именно первый пункт - быть специалистом лучшим, чем заказчик - он покупает именно вашу компетенцию и ответственность.

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

Думаю, если так подходить - то повторные заказы - дело времени.
Удачи на проектах
Designer1C; +1 Ответить
14. 1cNike 209 02.08.18 00:53 Сейчас в теме
(13) По поводу устава согласен. Обычно его делаю, и за весь ход проекта о нем вспоминают обе стороны от силы несколько раз. Протоколы лучше вести для каждой рабочей встречи. Даже если консультант просто поговорил с сотрудникам Заказчика, но при этом были приняты какие-то влияющие решения - лучше их зафиксировать под подпись.
К документам я бы еще добавил справку о статусе проекта. Краткая выжимка о текущем состоянии проекта - где находимся, что делаем, открытые вопросы, текущие риски и принятые/принимаемые по ним меры и т.п. На начальном/завершающем этапах проектов справку делаю не реже раза в неделю (обычно к совещанию по статусу проекта). В середине проекта раз в две недели/месяц.
17. skillman 5 30.11.20 03:43 Сейчас в теме
(13) Можете поделиться примерами документов к проектам?
15. 1cNike 209 02.08.18 01:20 Сейчас в теме
(0) Спасибо за статью, почерпнул для себя кое-что новое.
По поводу бюрократии и экономии времени при согласовании и подписании документов. Добавлю свой вариант, который использовал/использую на проектах для быстрого и упрощенного процесса подписания протоколов совещаний по статусу проекта. Раньше на некоторых проектах испытывал затруднения в получении подписи под "судьбоносными" протоколами на которых принимаются важные решения и т.п. Тратил на это какое-то время, т.к. никто не хочет подписывать такой документ первым, особенно если в проекте много политики. Приходится разными способами искать "слабое звено", которое подпишет протокол первым. :)
Теперь я добавляю в Устав строчку с обязанностью РП со стороны Заказчика в ознакомлении и согласовании принятых решений в проектных документах всеми участниками проектной группы со стороны Заказчика. Участники для ознакомления перечисляются в протоколе. Таким образом получив подпись РП со стороны Заказчика под протоколом я автоматически получаю согласование и всех перечисленных участников со стороны Заказчика. Договорится с одним человеком (РП) зачастую проще, чем с пятнадцатью. Участники проектной группы Заказчика зная эту особенность взаимодействия начинают активнее общаться со своим РП и решать внутренние вопросы по решениям перечисленным в протоколе практически без моего участия. Остается немного подождать и получить подпись, либо обоснованные изменения по принятым решениям.
kuril; kalyaka; Designer1C; +3 Ответить
16. kuril 57 06.08.18 15:50 Сейчас в теме
(15)

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


благодарю, попробуем
18. skillman 5 30.11.20 03:45 Сейчас в теме
Андрей, было полезным прикрепить примеры документов с проектов, которые вы считаете лучшим и успешным.
Устав, функциональную модель, приказ о назначении раб группы.
Естественно конфиденциальная информация меня не интересует, а вот посмотреть применение good practics хотел бы увидеть
Tushcan; Night_Trap; +2 Ответить
19. Tushcan 37 12.08.22 13:32 Сейчас в теме
(9)Спасибо за статью! Всё по полочкам. Согласна с предыдущим комментарием: хотелось бы увидеть примеры документов.
Оставьте свое сообщение