Отчет об обследовании 1с erp
Что такое монитор целевых показателей деятельности или, как модно сейчас называть, Dashboard в 1С?
До появления данного механизма мы привыкли видеть отчеты в виде таблиц. В них мы могли видеть финансовый результат, продажи и прочие показатели. Также могли в целом увидеть какую-то динамику по показателям, если устанавливали настройки по периодам за большой период.
Но не всегда удобно пользоваться таким предоставлением данных. Иногда хочется увидеть данные в графическом виде: с помощью различных графиков, диаграмм. Согласитесь, это в определенных случаях более удобно. Особенно для руководителей. Многие признают, что неудобно анализировать данные в табличном виде, им удобнее увидеть свои целевые показатели с помощью графической панели отображения данных.
1. Монитор целевых показателей деятельности в 1С:ERP. Включение подсистемы
Чтобы включить подсистему монитора целевых показателей необходимо в меню «НСИ и администрирование» в разделе «Настройка НСИ и разделов» в пункте «Финансовый результат и контроллинг» (рис.1) включить использование «Мониторинг целевых показателей» (рис.2).
После включения данной подсистемы в 1С:ERP 2.4 в разделе «Финансовый результат и контроллинг» появится раздел «Целевые показатели», который содержит пункты «Монитор целевых показателей», «Варианты анализа целевых показателей», «Категории целей».
2. Описание и настройка графической панели Цели показателей и вариантов анализа
Монитор целевых показателей – это графическая панель, в которой не нужно постоянно делать какие-то настройки, как в обычных отчетах, и данные представляются в виде гистограмм, графиков, диаграмм, конкретных цифр. Для того чтобы понять, как пользоваться монитором (dashboard), нужно определить, за чем мы будем следить. Допустим, интересует рост прибыли компании, т.е. необходимо отслеживать насколько выросла прибыль в том или ином периоде. Какие показатели влияют на этот рост? Снижение издержек, увеличение выручки и другое. Т.е. мы определяем, что мы будем анализировать и в каком виде нужно показать анализ: график, диаграмм и т.д. Определяем, за какой период, с какими отборами, а также каким пользователям это нужно показывать.
Прежде чем начать пользоваться монитором необходимо сначала задать «Категории целей» и для них «Варианты анализа целевых показателей».
Можно сразу переходить в варианты т.к. категории будут там также доступны.
В демо-базе и в поставке имеется уже готовая поставляемая модель показателей. Если создается новая база (пустая), то в ней нет этой модели. Но в комплекте поставки имеется файл МодельПоказателей, которую можно загрузить в чистую базу и донастроить под свои потребности.
В открывшейся форме видно, что она разделена на две части: левая часть – это как раз категории целей, а справа – варианты анализа.
Откроем, например, цель «Рост прибыли». Откроется форма, в которой мы видим описание цели и далее шаблон расчета целевого показателя. Т.е. любая цель должна быть чем-то измерима.
Шаблон расчета – это, по сути, схема компоновки данных 1С, которых достаточно много типовых. Можно настроить необходимые отборы ограничения, а также создать свои схемы.
Рассматриваем далее цель. Мы поставили цель «Рост прибыли». Далее мы должны определиться, к чему стремимся, чтобы максимизировать этот показатель, минимизировать или удержать его в каком-то диапазоне. Соответственно, если рассмотреть прибыль, то это скорее всего максимизация или удержание в диапазоне. Если издержки, то это минимизация или диапазон.
Целей может быть сколько угодно. Есть даже дерево целей. Например, глобальная цель это «Рост прибыли», чтобы ее достичь необходимо обеспечить «Рост валовой прибыли» и «Снижение косвенных расходов». Соответственно, чтобы обеспечить рост валовой прибыли, есть зависимые ниже цели и т.д.
Чтобы далее понять, есть ли рост прибыли или нет, справа для цели задается вариант анализа. Это может быть один или несколько вариантов. Можно также один и тот же показатель показать разными вариантами: цифрой, графиком или диаграммой.
В настройках варианта показателя выбираем данные: тип анализа, настройки периодичности, выбираем источник значения показателя, методы и точность расчета, дополнительные отборы, вариант контроля (день, неделя и т.д.), можно настроить ограничение доступности по пользователям.
Далее настраиваем внешний вид, где выбираем тип диаграммы, вариант отображения, дополнительная настройка оформления. Можем внести демо-данные для тестирования и представления.
В верхнем меню имеется пункт «Целевые значения». Это значения, показывающие к чему мы стремимся, и задав эти значения мы будем видеть отклонения. Если же не задать их, то будем просто видеть фактический результат.
3. Монитор целевых показателей 1С:ERP. Панель Dashboard в 1С
После того как все настроили можем обратиться к самому монитору целевых показателей, к панели dashboard. В мониторе есть фильтры по периодичности контроля показателей.
По отборам состояния цели.
Можем перейти и расшифровать влияющие показатели, открыть отчеты расшифровки 1С.
Анализируемый показатель прибыли с расшифровкой по влияющим показателям.
Расшифровка показателя «прибыль».
В заключение можно добавить, что данный монитор с нужными показателями можно настроить под конкретного пользователя и задать параметр, чтобы при запуске программы сразу открывался данный монитор. Также для показателей задается интервал обновления, например, чтобы через каждые 15 минут показатели на мониторе обновлялись.
Специалист компании ООО «Кодерлайн»
Вас могут заинтересовать следующие статьи:
94 [PROP_CODE] => TAGS2 [TITLE] => Вас могут заинтересовать следующие семинары: ) --> 95 [PROP_CODE] => TAGS [TITLE] => Вас могут заинтересовать следующие вебинары: ) -->
Вас могут заинтересовать следующие вебинары:
В данной статье мы рассмотрим наш опыт внедрения систем 1С:ERP 2 c точки зрения ключевых проблем проектов, на которые Заказчики обычно не обращают внимания. Но именно эти сложности очень часто являются критическими, влияющими на успех всего проекта. Мы уже 15 лет занимается проектами внедрения корпоративных систем и накопили достаточно богатый опыт. Рынок внедрения систем 1С:ERP 2 в том числе управление предприятием, на данный момент очень активный, многие компании запускают подобные проекты или планируют запускать в ближайшем будущем. Мы надеемся, что описание ключевых проблем подобных проектов, приведенное в данной статье, поможет компаниям выработать правильные решения для достижения поставленных целей.
А теперь, рассмотрим проблемы внедрения 1С:ERP в порядке частоты их возникновения.
Заказчик надеется получить точную оценку стоимости и сроков проекта еще на этапе предварительных переговоров с Исполнителем, без всякого обследования и подробного анализа.
Наш опыт внедрения систем 1С ERP 2 показывает, что распространенное убеждение некоторых Заказчиков состоит в том, что, пообщавшись с потенциальным Исполнителем 2-3 раза по телефону и скайпу, предоставив данному Исполнителю краткие обобщённые функциональные требования на 3-5 страниц, можно получить точную оценку стоимости и срока проекта. К сожалению, на практике это физически невозможно.
Крупные ИТ проекты, а тем более, внедрение ERP систем: индивидуальны, сложны и часто подвержены изменениям в процессе реализации. В таких ситуациях ошибки в первоначальных оценках «без погружения» в 30-40% считаются нормальными с точки зрения даже общемировой практики. Но Заказчики, чаще всего, не готовы это учитывать, виной тому ряд факторов:
- Собственник или Топ-менеджер Заказчика желает знать точную оценку проекта «до копейки» еще на этапе выбора Подрядчика, и это, часто, один из основных критериев выбора.
- Собственник или Топ-менеджер Заказчика не желает оплачивать услуги предпроектного обследования нескольким Подрядчикам, рассуждая с точки зрения экономии средств.
- Собственник или Топ-менеджер Заказчика не понимает специфики оценки и управления крупными ИТ проектами и пытается применить для них общепринятую методологию, основанную на своем управленческом опыте в других сферах: нужна точная оценка, а работать будем по принципу «сначала готовая система (или ее части), а потом деньги». Заказчик пытается таким образом максимально себя обезопасить, переложив все возможные риски на Исполнителя.
К сожалению, в сфере внедрения ERP систем, а тем более системы 1С:ERP 2, все это имеет достаточно печальные последствия:
- Подрядчика выбирают по принципу «кто дешевле предложит» или «кто пойдет на наши жесткие условия», причем Подрядчики часто делают оценки проектов «на глаз», «без детального погружения в специфику» и тут риски сформировать сильно неправильный бюджет для проекта становятся очень серьезными. А заниженный в 2-3 раза бюджет, это огромный риск провала, либо сильного уменьшения границ проекта и не достижения необходимых целей и задач.
- Проект выполняется в обстановке отсутствия нормального доверия между Заказчиком и Исполнителем и желания вместе двигаться к одной цели. Исполнитель пытается максимально сузить круг задач и сократить содержание проекта, чтобы попасть в этот «небольшой» бюджет, а Заказчик пытается получить от Исполнителя как можно больше, аргументируя это тем, что «Вы же сами этот бюджет и назвали, вот теперь и делайте». Как показывает наш опыт внедрения систем 1С:ERP 2, такие вещи обычно не ведут ни к чему хорошему: результаты и качество проекта сильно страдают, проект вообще может закончится неудачей.
Как на практике решать такие проблемы внедрения 1С:ERP? Нам кажется, что тут прежде всего необходимо проводить разъяснительную работу с ЛПР (лицами, принимающими решения) Заказчиков: объяснять особенности проектов внедрения ERP систем, особенности оценки таких проектов, раскрывать методы управления проектами, показывать риски и сложности. И только в случае достижения взаимного понимания и уважения интересов Заказчика и Исполнителя, в случае понимания особенностей и сложностей управления крупными ИТ проектами, только в этом случае Стороны будут способны успешно решить поставленные задачи.
В противном случае, мы считаем, что грамотному Исполнителю лучше просто отказаться от выполнения проекта, в котором нет понимания и согласия с Заказчиком, но тут конечно каждый Подрядчик сам для себя решает, что для него важнее.
Со стороны Заказчика в проекте внедрения нет достаточно компетентного, мотивированного, обладающего свободным временем и полномочиями Руководителя.
Как показывает наш опыт внедрения систем 1С:ERP 2 для управления предприятием, часто эту проблему недооценивают, но она вполне может стать решающей для успеха проекта.
Тут возможны следующие варианты проблемы:
- Компетентный Руководитель внедрения 1С: ERP есть, и он обладает необходимыми полномочиями, он вполне может быть топ-менеджером компании (например, финансовый или ИТ директор), но у него просто нет свободного времени, чтоб посвятить себя проекту. У данного специалиста множество других задач и обязанностей и он будет заниматься внедрением 1С:ERP 2 по «остаточному» принципу.
- Компетентный Руководитель есть, у него есть время, необходимый опыт и знания. Но нет необходимых полномочий. Его просто никто не слушает. Такая проблема часто случается, если под проект нанимают нового специалиста, наделяют его необходимой ответственностью, зато забывают его наделить необходимыми полномочиями. Высшему руководству компании необходимо понимать: ответственность и полномочия взаимосвязаны.
- На должность Руководителя назначают недостаточно мотивированного и компетентного специалиста, по принципу «кто сейчас свободен, или кто что-либо понимает в ИТ технологиях». Но этого часто совершенно недостаточно. Бывает, что такой руководитель не обладает необходимыми навыками и мотивацией для продвижения проекта внутри компании Заказчика.
Подводя итог вышесказанному, ЛПР и топ-менеджмент Заказчика должны осознавать проблему назначения компетентного и мотивированного Руководителя проекта, обладающего временем на решение задач проекта, и наделения его необходимыми полномочиями. Внедрение систем 1C:ERP 2, это совместный труд команд Исполнителя и Заказчика, а грамотный Руководитель проекта со стороны Заказчика — один из ключевых факторов успеха внедрения 1С:ERP.
Понимание целей и задач внедрения ERP-системы у всех разное – у Руководителя проекта (РП) Заказчика, у Руководителя проекта Исполнителя, у руководства и топ-менеджеров Заказчика.
Казалось бы, что такое невозможно, но очень часто Стороны и заинтересованные лица проекта видят цели и задачи совершенно по-разному. Кроме того, опыт внедрения систем 1С:ERP 2 показывает, что Стороны проекта могут не понимать так же критерии достижения целей. Ведь слова «внедрена 1С:ERP 2» могут значить совершенно разное и для каждой Стороны проекта совершенно свое. Рассмотрим примеры.
- В понимании РП Заказчика система внедрена, если в ней работают все запланированные пользователи
- В понимании топ-менеджмента Заказчика система внедрена, если в ней можно сформировать необходимую для принятия управленческих решений отчетность
- В понимании собственника Заказчика, система внедрена, если можно оценить и спрогнозировать возврат инвестиций от ее внедрения
- В понимании РП Исполнителя, система внедрена, если в ней автоматизированы все запланированные на старте проекта функциональные блоки
- И т.д.
Поэтому, часто бывает полезно в процессе инициации работ по проекту обсудить со всеми заинтересованными Сторонами их видение целей и задач внедрения, и что особенно важно — критериев достижения целей.
Кроме того, чтобы зафиксировать это согласованное видение в самом начале, часто достаточно полезно сформировать и согласовать некий стартовый документ, например, «Устав проекта» или «Концепцию проекта».
У Заказчика и Исполнителя разное понимание методологии управления проектом: как выполнять работы, как сдавать и принимать работы, как оплачивать работы.
По нашему опыту выполнения внедрений 1С: ERP 2, проблема состоит в том, что Заказчик зачастую не достаточно разбирается в методологии управления ИТ проектами: до начала работ он не представляет, как будет организована сдача – приемка работ, в какой момент это будет происходить, как будет организована сама работа.
Кроме того, Заказчик часто не до конца понимает уровень вовлеченности и нагрузки, который ляжет на его собственных специалистов в процессе выполнения проектных работ. Какие самые распространенные проблемы здесь встречаются?
Стороны согласовывают применение «гибкой» методологии управления проектом (Agile/Scrum/1C:Технология быстрых результатов), но Заказчик не совсем понимает, что это значит. Когда закачивается «спринт» и не все задачи «спринта» выполнены, Он начинает требовать с Исполнителя закончить все задачи «спринта», отказываясь подписать акт сдачи-приемки работ. Либо еще вариант – «спринт» закончился, реализовали какие-либо доработки, но Заказчик отказывается их принимать, ссылаясь на их «сырость» и что «тут еще не хватает кнопок, функций и печатных форм». Но это нормально для «гибкой» методологии. Она подразумевает итеративно-импликативный процесс наращивание функционала и доработки системы. В итоге все будет доделано, но на последующих этапах внедрения, но отказ работать в рамках принятой методологии тормозит работу.
Заказчик хочет детально управлять стоимостью, но не хочет подробных Технических проектов и Технических заданий. С одной стороны, хочется управлять ценой работ по проекту «до копейки», но с другой стороны – «мы сейчас точно не знаем, что делать, по ходу выполнения работ и разберемся». Это явные противоречия Agile/Scrum и «Каскадной» (Waterfall) модели. В такой ситуации Заказчику надо еще раз подумать и решить, что же все важнее для него: гибкость и скорость запуска, либо детальное управление стоимостью и исходя из этого выбрать методологию управления и финансирования проекта. Иначе модель финансирования проекта и модель управления проектом начинают входить в явные противоречия и это обычно ведет к большим проблемам в реализации.
Иногда Заказчик не понимает, что необходимо выделять временные ресурсы своих бизнес-экспертов для взаимодействия с командой Исполнителя. Он считает, что «Исполнители сами все сделают, им же деньги платят». Такое утверждение несколько не справедливо для внедрения системы 1С: ERP 2. Стороны проекта должны четко осознавать, что ERP система постепенно «вплетается» в процессы предприятия и развертывается, охватывая почти все сферы деятельности компании. Исполнители - профессионалы в области внедрения ЕРП систем, но они не разбираются в бизнесе Заказчика. Поэтому тут нужна только совместная работа.
Какие есть пути решения проблем внедрения 1С:ERP? Как показывает наш опыт, это, прежде всего, честная и открытая коммуникация между обеими Сторонами. Не замалчивание проблем, а их открытое обсуждение и выработка совместных идей и решений. Только сотрудничество и доверие между Сторонами проекта может помочь в решении такой сложной задачи, как внедрение системы 1С:ERP 2.
Низкий уровень поддержки со стороны руководства или части топ-менеджмента Заказчика.
Как ни странно, но наш опыт показывает, что проблема слабой или формальной поддержки проекта со стороны Руководства Заказчика является достаточно распространенной. Какие здесь бывают варианты?
Проект Руководству компании «навязали» Собственники или вышестоящее холдинговое начальство. Руководство компании не верит в успех. Развитие такой ситуации может быть двойственным: либо Руководство компании совершенно дистанцируется от проекта и постарается его не замечать, либо будет открыто вступать в конфронтацию с проектной командой и мешать реализации. На самом деле и тот и другой вариант – губительны для проекта. Наше мнение, если при внедрении ERP системы не удается заручиться поддержкой руководства компании, то такой проект лучше не начинать.
Руководство Заказчика формально поддерживает проект, но ничего не делает для решения сложных административных задач и конфликтов. Из такой ситуации можно попробовать выйти через попытки коммуникаций и вовлечения Руководства компании в проект: демонстрация промежуточных результатов, участие в выработки решений, донесение ценности проекта для Руководства. Но если «достучаться» до Руководства компании не удается, то в большинстве случаев подобные проекты обречены на неудачу.
В конечном итоге, мы пришли к выводу, что поддержка со стороны Руководства компании – ключевой фактор, без которого масштабные внедрения ERP систем обычно не достигают успеха. Поэтому, мы стараемся еще на этапе предварительных переговоров понять уровень поддержки со стороны Руководства компании и если понимаем, что этот уровень низкий или формальный, то мы обычно отказываемся от таких работ.
Мы рассмотрели с основные проблемы, которые Заказчики часто не замечают и недооценивают в проектах внедрения систем 1С:ERP 2, пытаясь больше сосредоточиться на технической стороне задачи. Но для успеха проекта Стороны должны быть готовы к честному и открытому сотрудничеству без явного «перетягивания одеяла». Внедрение систем 1С:ERP 2 обычно не делается в одиночку. Как показывает практика, только стратегия открытого взаимодействия Заказчика и Исполнителя, стратегия доверия, коммуникации и сотрудничества является успешной и приводит проекты внедрения систем 1C:ERP 2 к высоким бизнес результатам.
Предлагаем вниманию анкеты, используемые для оценки объема проекта внедрения. Анкеты могут использоваться на этапе экспресс-обследования. На более поздних этапах требуется углублять собираемую с клиента информацию для проектирования системы на базе 1С:ERP Управление предприятием 8.
Приведены опросники по следующим функциональным участкам, автоматизируемым с помощью программного продукта 1С:ERP:
- Раздельный учет затрат (в том числе для целей учета по ГОЗ);
Специальные предложения
Специалист, выполняющий анкетирование готов к тому, что пользователь может задать уточняющие вопросы и рассказать бизнес кейс по каждому из вариантов ответа.
А так же учесть момент что анкетируемый может ответить - у нас сейчас делается так, но вот пример который вы привели по такому то пункту нам интересен и мы подумаем, обсудим и захотим сделать по другому.
Или это раздаточный материал?
(1) Анкетирование по идее не должен проводить начинающий специалист. Тут нужен человек, который способен выявить потребности заказчика.
Большое спасибо автору за материалы.
(2)
Я встречал на рынке 2 подхода:
- мы считаем, что это ключевой этап будущего проекта. и то, как мы поймем потребности клиента и сформируем ожидания - залог успешности будущего внедрения. Соответственно, у нас экспресс-обследования проводят Руководители проектов или самые опытные консультанты.
- видел ситуацию, когда продажа и выполнение проектов поставлены совсем на поток. И задача экспресс-обследования - по сути, создать у клиента восторженное представление о будущем проекте и заключить договор. Большинство таких проектов завершается очень средним результатом. Ожидания заказчика оказываются обманутыми. Но на потоке такая схема зарабатывания денег работает. Проекты должны быть не очень крупные, конечно.
(1)
Конечно, готов. Качественно провести экспресс-обследование, просто отправив анкеты, у нас не получается.
(5)
Жаль, что вызвал у Вас недоверие. Но, если честно, даже не задумывался о том, что скриншоты могут быть правильными или нет :)
(13)
:) Нет. Это анкеты, которые разработаны целенаправленно и используются РП/консультантами ВЦ Раздолье на экспресс-обследованиях.
Рука-лицо. Шел 21 век. Мы внедряли ЕРП как могли.
Может стоит поменять подход к внедрению?
(8) Я видел их, но ЕРП не панацея(да внутри сделано много), но то что выдают за результат проекта внедрения таковым не является.
(10)
Коллеги, потерялся в иносказаниях. Если есть критика - буду рад слышать - будет возможность что-то улучшить.
Сложно представить, как эти анкеты вообще можно использовать в оценке объема проекта? Например, пункт 2.1.3 первого снимка экрана "Как рассчитывается план производства" - какой ответ предполагается уместить в эту крошечную ячейку - "Да"? :-)
Как конкретно ответ может повлиять на результат оценки объема проекта?
(15) Конечно же предполагается, что ответственный пользователь приложит к анкете распечатку своей екселевской формы образца плана производства с пометками какие цифры откуда берутся и как считаются.
(16) и как это влияет на оценку - приложил 5 листов распечатки, к оценке добавилось 5 млн, а приложил 10 листов, то 10 млн? :-)
Где-то есть у вас пример, показывающий, как этот пункт меняет результат оценки в зависимости от ответа?
Написал в графе ответ есть/нет и все стало бесплатно.
(17) например возможны варианты
Планирование по показателям прошлого года
по заключенным договорам/ долгосрочным контрактам
Текущим заявкам..
. Использовать для обследования еще худо-бедно пригодятся, но оценка объема внедрения по таким анкетам менее надежная, чем по методу "Три П" при совсем не сопоставимых трудозатратах.
(15)
Мы почти не используем анкеты без участия Консультанта/РП, который проводит опрос. Основная задача вопросов - не забыть обсудить какие-то темы.
А по поводу того, что вопросы типа 2.1.3 не влияют на оценку, я бы не сказал. Очень грубо можно вот так учесть ответ:
· Нет и не требуется. Это означает, что соответствующая функциональность не требуется в проекте.
· Сейчас нет, но готовы рассмотреть возможности. Значит, планируем, что подсистема будет, но в близком к типовому варианте (потому что пользователей можно будет убедить на вариант 1С).
· Если Заказчик рассказывает какие-то осмысленные схемы, и Заказчик понимает, что хочет, то закладываем в стоимость подсистему + небольшое количество доработок (потому что на типовую их вариант может и не лечь)
· Если Заказчик рассказывает о своем «сложном» процессе (а такое часто бывает). Это означает, что подсистема не просто будет, но и скорее всего будет нетиповая. Так что в стоимость проекта стоит заложить побольше доработок по данному блоку.
Где он в этой анкете рассказывает в пункте 2.1.3 - "галочку" проставил или написал "все сложно" и у вас включается оценочный мультипликатор с результатом "очень дорого"? :-)
И задача экспресс-обследования - по сути, создать у клиента восторженное представление о будущем проекте и заключить договор.
Стоимость рассчитывает РП, исходя из планового объема работ.
Повторюсь. Анкета база для опроса. Опрос производит РП или Ведущий консультант.
Нет. Не для этого.
Анкет быть не должно! На заре автоматизации, я садился на место работника и говорил ему: - Учи, тому что делаешь сам! Потом составлялась схема на одном листке (Что, кто, кому, куда, зачем) Потом обсуждался этот листок. Потом если была необходимость, то писался алгоритм - прямо словами друг за другом все этапы работы. Потом обсуждалось, как улучшить ситуацию. Как можно делать то-что надо. ничего не делая. Например, тот же производственный план - откуда берется? Из заявок. кто их получает, кто пишет на них состав материалов, а кто сроки? Кто стартует процесс? Кто обеспечивает? Что сами делаете? что в переработку? А всегда ли сами делаем все одинаково, а куда брак, а где ПФ. А кто регистрирует? А кто выдает. И все это непосредственно на производстве, а не в кабинете главного инженера.
Тогда можно создать процесс глобальный, а когда вы знаете только программу и способы ее настройки, То совсем не факт, что это именно то, что нужно.
(25)
Я с Вами согласен.
Только Вы описываете, скорее, уже процесс Функционального моделирования (термины могут быть разными; часто - "обследование"), когда нужно спроектировать как бизнес-процесс (улучшенный) будет реализован в системе.
Эти анкеты - для более раннего этапа - для экспресс-обследования. Когда за несколько дней эксперту нужно оценить общие границы проекта, продолжительность плановую и цену проекта.
(26)
И тут согласен. Анкета - просто инструмент, чтобы что-то не забыть из того, что планировал обсудить.
Друзья, мы заявили мастер-класс по автоматизации предприятий оборонно-промышленного комплекса на ближайший Инфостарт Эвент.
В мастер-классе мы расскажем о том как продавать проекты в оборонке, о специфике их выполнения, о том какая специфика в настройке 1С:ERP существует для предприятий ОПК.
Автор мастер-класса - эксперт ВЦ Раздолье по автоматизации предприятий ОПК - Пикурен Вера.
Коллеги, кто заинтересован в том, чтобы принять участие в мастер-классе приглашаю проголосовать за него на сайте Инфостарта.
Адрес страницы с проектами докладов https://event.infostart.ru/2019/agenda/
Мастер-класс Веры заявлен внизу страницы в разделе "Мастер-классы".
Друзья, можете поделиться анкетой для проведения обследования в регламентированном учете (БУ и НУ)? Спасибо
Коллеги, можете помочь с анкетой на проведение обследования по регламентированному учету (БУ и НУ)? Что там писать? Спасибо
Кейс
Предпроектное обследование предприятия Заказчика
Компания по обслуживанию и управлению бизнес-подразделениями Холдинга
(декабрь 2016 — январь 2017)
Заказчик: Компания по обслуживанию и управлению бизнес-подразделениями Холдинга, Удмуртская Республика
Отрасль: Развиваются несколько бизнес направлений: девелопмент, строительство зданий и сооружений, генеральный подряд, строительство наружных трубопроводов, нефтедобыча, производство бетона и раствора, добыча строительного песка, производство питьевой воды, автоматические автозаправочные станции.
Краткая справка о заказчике: Компания является головной организацией в холдинге. Главная задача которой — максимально эффективное управление холдингом и обслуживание бизнес-подразделений. В холдинге насчитывается порядка 100 юридических лиц. Одна из компаний входящих в холдинг является третьей по величине в России среди независимых предприятий по нефтедобыче.
Направление девелопмента осуществляет строительство жилой и коммерческой недвижимости в нескольких регионах России и является одним из лидеров рынка Удмуртии по вводу жилья.
Один из главных принципов работы холдинга — это ориентация на постоянный профессиональный рост сотрудников. Для менеджмента и специалистов компании организуются обучение и тренинги в ведущих российских и зарубежных университетах.
Компания постоянно развивается и охватывает новые виды бизнеса.
Исходная проблема и задачи
Необходимо было провести предпроектное обследование предприятия Заказчика, предложить оптимальный набор информационных систем, выработать подход к реализации проекта.
Предложенное решение
Определить бизнес-процессы верхнего уровня
Определить процессы, участвующие в автоматизации
Определить требования к уровню автоматизации выбранных процессов и первичная оценка соответствия стандартным возможностям системы
Определить границы проекта по автоматизации предприятия
Согласовать архитектуру информационных систем
Согласовать план проекта автоматизации предприятия
Результат
Проведенное интервью со всеми участниками процесса автоматизации, со всеми руководителями бизнес-направлений
Описанные бизнес-процессы предприятия
Согласованные процессы, участвующие в автоматизации
Архитектура информационных потоков и ПП
Привязка автоматизируемых процессов к функционалу выбранных ПП и владельцам БП
Требование к автоматизируемым процессам Заказчика
Разработанная структура НСИ
Отчет об обследовании с описанием бизнес процессов
Выбранный ключевой продукт для автоматизации — «1С:ERP Управление предприятием»
В ходе реализации проекта были автоматизированы следующие направления производственной деятельности:
В ходе данного этапа организации внедрения проекта выполняется сбор основных сведений о текущей ситуации у Заказчика, проводится интервьюирование ключевых пользователей будущей системы, изучение текущих учетных систем. По итогам предпроектного обследования структурируется полученная информация, которая позволяет оценить сроки, фазы и этапы всего проекта, а также его бюджет. В качестве итогового документа предоставляется «Отчет об экспресс-обследовании».
Основной ценностью этапа предпроектного обследования для Заказчика является получение зафиксированного скоупа проекта и знакомство с ключевыми участниками проектной команды (руководитель проекта, архитектор)
2. ЭТАП 2. Моделирование внедрения проекта 1С
Суть процесса моделирования при внедрении проекта 1С – наложение реальных процессов организации на имеющиеся механизмы отражения подобных бизнес-процессов в типовой конфигурации от 1С и фиксация функциональных разрывов – различий, требующих донастройки или серьезной доработки системы.
На данном этапе разрабатывается функциональная модель целевой системы, формируются требования к подготовке отчетности, утверждаются состав требуемых аналитических разрезов.
Выполняется проработка решений по способам автоматизации с подготовкой прототипа системы и написанием документа «Концептуальный дизайн», в котором фиксируются и описываются все принятые решения на типовом функционале. Будут проведены демонстрации практической реализации различных процессов и настроек в демо-базе, отработаны сквозные примеры, соответствующие специфике бизнес-процессов Заказчика.
Сам процесс моделирования в значительной части проходит в плотном взаимодействии сотрудников Исполнителя и Заказчика: сотрудники Заказчика активно вовлекаются в работу, производится обучение ключевых сотрудников и экспертов Заказчика. Со стороны Заказчика выполняется уточнение и актуализация учетных политик регламентированного и управленческого учета, действующих регламентов и процессов управления. Состав регламентов определяется внедряемыми подсистемами.
Концептуальный дизайн – документ, содержащий описание бизнес-процессов, подлежащих отражению в системе. По сути, это описание системы «To be».
Реестр функциональных разрывов – документ, содержащий перечень требований на доработку с табличным представлением результата.
Моделирование внедрения проекта системы 1С ведётся по блокам, короткими итерациями при наличии активной взаимосвязи по схеме:
создание модели → демонстрация → корректировка модели
3. ЭТАП 3. Проектирование внедрения 1С
На данном этапе положения и требования, зафиксированные ранее, преобразуются в конкретные проектные решения. Проектные решения описываются в частных технических заданиях (ЧТЗ) на каждую модификацию (доработку).
Несмотря на кажущуюся обязательность данного этапа внедрения проекта 1С, наша практика показывает отсутствие необходимости составления единого технического задания и технического проекта на всю систему после выполнения этапа «Моделирование».
Т.к. все функциональные разрывы с типовой конфигурации 1С описываются по итогам этапа «Моделирования», этой информации нашей команде в большинстве случаев достаточно для реализации всех доработок системы.
С учетом тренда на максимальное использование типового функционала при внедрениях, мы стараемся идти по пути минимального количества доработок системы, при этом используется механизм расширений, сохраняющий типовую конфигурацию для беспроблемных обновлений.
Тем не менее в ряде случаем мы включаем данный этап в проект, особенно если предстоит значительная адаптация системы. Выходным документом данного этапа является документ «Техническое задание» (ТЗ), частное технические задание или «Технический проект» (ТП).
4. ЭТАП 4. Разработка и тестирование информационной системы
На данном этапе реализуются доработки в информационной системе, после чего по каждой доработке проводится процедура приемо-сдаточных испытаний (ПСИ). При этом проводится как сценарное тестирование информационной системы, так и нагрузочное (при необходимости).
В случае проведения нагрузочного тестирования информационной системы и подготовки его результатов необходимо привлечение специалистов, компетенция которых подтверждена компанией 1С (сертификация 1С:Эксперт по технологическим вопросам).
5. ЭТАП 5. Обучение пользователей типовой конфигурации 1С
На данном этапе производится обучение участников проектной команды и подготовка пользовательской документации.
В соответствии с разработанным и согласованным планом обучение производится как в очном формате, так и в формате вебинаров. Обучение включает в себя как теоретическую, так и практическую часть.
На основании нашего опыта, мы рекомендуем проводить обучение сотрудников, занятых на проекте как можно раньше, возможно, даже до начала предпроектного обследования. Это позволит сотрудникам быть максимально вовлеченными в процесс за счет лучшего восприятия системы и ее особенностей.
6. ЭТАП 6. Подготовка к эксплуатации информационной системы
На данном этапе выполняется:
· развертывание ИС в рабочей среде;
· настройка системы для отражения всех включенных в проект бизнес-процессов;
· настройка прав и ролей пользователей;
· перенос исторических данных из ранее использовавшихся систем;
· интеграция со смежными системами;
· выверка и корректировка данных;
· развертывание системы на рабочих местах пользователей.
7. ЭТАП 7. Опытно-промышленная эксплуатация информационной системы
Опытная эксплуатация информационной системы проводится Заказчиком при поддержке Исполнителя на реальных данных посредством ввода данных и получения необходимой отчетности одновременно в двух системах – исторической и создаваемой с целью найти отклонения в работе функционала новой информационной Системы. Срок опытной эксплуатации информационной системы устанавливается по согласованию сторон в пределах от 1 до 3 месяцев.
На стадии опытной эксплуатации информационной системы производится поддержка и сопровождение системы силами Исполнителя: происходит устранение замечаний, производится дополнительное обучение пользователей в процессе их работы в реальных условиях, осуществляется консультационная помощь при работе с системой.
Специалист компании «Кодерлайн»
Вас могут заинтересовать следующие статьи:
94 [PROP_CODE] => TAGS2 [TITLE] => Вас могут заинтересовать следующие семинары: ) --> 95 [PROP_CODE] => TAGS [TITLE] => Вас могут заинтересовать следующие вебинары: ) -->
Вас могут заинтересовать следующие вебинары:
Читайте также: