Существует ошибочная точка зрения, что наиболее критичным этапом внедрения ERP-системы является разработка, это не совсем так. Немаловажны активности, связанные с тестированием, обучением и миграцией данных. Однако все это задачи, выполняются на стороне заказчика. В проект имплементации корпоративной информационной системы вовлечены и прочие заинтересованные стороны, в честности контрагенты [1]. Несмотря на то, что вопрос перехода к продуктивному использованию системы является ключевым в ходе запуска, его важность иногда недооценивается. По крайней мере, до тех пора пока вы не столкнетесь с Cutover’ом вплотную. Да, да, именно так называют план перехода в среде технических специалистов.

План перехода включает в себя ряд активностей, выполнение которых решает две основные задачи: техническая подготовка программного решения для функционирования в режиме реального времени, а также взаимодействие с клиентами и поставщиками для обеспечения непрерывной работы с ними. Cutover-план затрагивает технические, бизнес и вопросы, связанные с историческими данными [2]. Формирование плана перехода начинается много раньше промышленного запуска, так как задача в первую очередь требует большого вовлечения сотрудников заказчика, во-вторых, сильно зависит и влияет на технические активности смежных команд.

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

Имплементация корпоративной информационной системы требует вовлечения большого числа участников для решения задач управления проектом, моделирования бизнес-архитектуры, реализации программного обеспечения, миграции данных, подготовки технической инфраструктуры и обработки изменений [1].

Ключевым содержанием подобных проектов является разработка программного продукта, а все остальные активности рассматриваются в качестве поддерживающих. Реализация программ может вестись на основе различных стратегий, следуя классическим моделям разработки: каскадной, итерационной и спиралевидной. Проекты имплементации информационных систем «с нуля» преимущественно ведутся на базе каскадной стратегии, а задачи тиражирования и развития систем в последнее время осуществляются с применением итерационных и спиралевидных подходов, например, Agile [2].

Следуя каскадной схеме внедрения программных продуктов, готовится ряд важных проектных документов, описывающих детали предлагаемого решения. В большинстве проектов имплементации систем класса ERP, создаются документы спецификаций на разработку [3]. В России действуют ГОСТ 34, посвященный разработке автоматизированных систем управления (далее – АС). Согласно ГОСТ 34.601-90 этапы разработки системы включают:

Агрессивная, навязчивая реклама товаров, работ, услуг, продвижения бренда в PR-технологиях и маркетинге компаний сегодня начинает давать «обратный» эффект и со временем в таком формате уйдет в прошлое. Новой технологией подачи информации становится сторителлинг, который активно используется как коммуникационный метод продвижения бренда. Сегодня выделиться в огромном количестве информации в информационном потоке стало намного сложнее, поэтому сторителлинг – один из способов это сделать. Сторителлинг (Storytelling) – термин, употребляемый маркетологами, журналистами, психологами, преподавателями и понимаемый как коммуникативная технология, позволяющая посредством нарратива сделать информацию интересной и запоминающейся для адресата. Технология сторителлинга, или рассказывания историй, за последние несколько лет приобрела заметную популярность; она используется в различных профессиональных средах. Изначально сторителлинг был успешно внедрен и апробирован Дэвидом Армстронгом как инструмент управления персоналом. Затем этот метод  начал активно использоваться в маркетинге, PR, журналистике, образовании. 

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

Внедрение корпоративных информационных систем позволяет автоматизировать большинство административно-хозяйственных операций предприятия. Класс системы, например, ERP, ERP2 или MRP, специфицирует бизнес-процессы, подлежащие автоматизации. Имплементация ERP-систем затрагивает две ключевые области деятельности компании: логистику и финансы. Причем специфика страны накладывает свой отпечаток: в Европе преимущественно акцент делается на логистических операциях, в России, напротив, – финансовых [1]. Для обеспечения эффективной работы ERP-системы необходимо обеспечить разумный баланс между логистическими и бухгалтерскими требованиями, их реализацией в программной системе.

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

Следует отметить, что, несмотря на кажущуюся простоту закупок, процесс ее отражения в ERP-системе достаточно непрост. Существуют различные виды закупок, каждая их которых имеет свои отличительные особенности и требует уникальной реализации в программной системе [2]. Зачастую в проектах внедрения ERP-систем цепочки закупок имеют сложную реализацию из-за необходимости удовлетворения бухгалтерским требованиям. Давайте рассмотрим схемы закупок, точки интеграции с финансовыми операциями и найдем способ их отражения в ERP-системе.

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

Несмотря на важность вопроса мигрирования данных корпоративных информационных систем, литературных источников, дающих исчерпывающее представление о переносе информации не так много. Но даже в них есть изъяны: или слишком поверхностное описание, или излишняя детализация, исключающая стратегию как таковую. Примером первой категории работ служит статья [1], повествующая о миграции данных в SAP ERP, однако тонкости и детали переноса основных и переменных данных в ней не раскрыты. Прочие работы [2-3] дают максимум информации по автоматизированным средствам переноса данных в той же системе SAP, хотя взаимосвязь между техническими средствами и концепцией, стратегией, видением не прослеживается. Все это подчеркивает необходимость детального анализа миграции данных ERP-систем, что особенно актуально для транзакционных информационных систем.

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

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

Прежде всего, определимся с терминами. Что такое аудит? Это проверка бухгалтерской отчетности юридических (в отдельных случаях и физических лиц) на предмет достоверности данных. Причем эти данные должны соответствовать как показателям бухгалтерских регистров в электронной базе (например, та же 1С), так и сведениям из первичных документов [1].

Осуществлением аудита занимаются представители профессии под названием «аудитор». Этапы процесса проведения аудиторской проверки показаны на рис.1.

Внедрение практически любой корпоративной информационной системы требует ее доработки для реализации как законодательных, так и специфических требований предприятия. Согласно [1], стандартный функционал КИС покрывает не более 30% бизнес-требований, все оставшиеся – реализуются разработками и донастройками системы. Ведение доработок ERP и ERP2-систем (ERP, Enterprise Resource Planning) – задача нетривиальная по причине того, что разрабатываемая программа должна успешно решать сформулированную бизнес-задачу, быть масштабируемой и расширяемой, а также не нарушать работу смежных модулей системы.

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

К сожалению, число литературных источников, посвященных проектированию и разработке подобных программ, не так велико, более того существует следующая крайность: либо повествование ведется исключительно для аудитории разработчиков, преимущественно описывая алгоритмы обработки данных, их оптимизацию и построение соответствующей структуры программы [3-5], либо теоретических проектировщиков – вводя всевозможные классы и типы систем и подпрограмм, банальные принципы и требования, не очевидные к реализации, что не дает ответа на вопрос, как правильно моделировать программу и отражать ее в задании на разработку. Конечно существуют различные ГОСТ’ы в области информационных систем [6, 7], однако подобные документы преимущественно описывают постановку задачи и требования к результатам нежели содержательную часть решения. Именно поэтому процесс проектирования программ весьма критичен и напрямую влияет на качество имплементации ERP/ERP2-систем.

Информация определяется как сведения о лицах, предметах, фактах, событиях, явлениях и процессах независимо от формы их представления [1]. Объектом правового регулирования могут быть конкретные формы существования информации: 

Миграция данных является одним из ключевых и самых сложных аспектов внедрения SAP: непродуманная стратегия может поставить под угрозу весь проект. Несмотря на то, что миграция данных является частью плана по внедрению (Cutover Plan), её важность очень часто недооценивают и весь процесс рассматривается как простая административная задача по переносу данных из одного места хранения в другое. Команда сосредотачивается на дизайне и демонстрации системы (Workshop), а также конфигурации, оставляя планирование миграции на потом. В результате на активности по миграции закладывается недостаточно времени и ресурсов, что может привести к срывам сроков при запуске. Грамотно спланированные миграционные активности помогут избежать «кранча» в период подготовки, а также снизят риски после запуска проекта. 

Если целью внедрения SAP ERP является замена старой (Legacy) системы, то миграция позволит перенести релевантные бизнес-данные из Legacy в соответствующие SAP-модули. Процесс миграции включает в себя следующие этапы [1]:

История дизайн-мышления (design thinking) началась более полувека назад, когда Герберт Саймон озвучил идею дизайн-мышления в 1969 году в книге «Науки об искусственном» (The Sciences of the Artificial). В своей работе он привёл тезис об общности творческого подхода к различным видам деятельности, будь то написание музыкального произведения или, например, разработка техники [1].

В 70-80-х годах прошлого века этот подход проникает в менеджмент. В 1978 году Дэвид Келли создаёт вместе со своим университетским другом Дином Хови компанию Hovey-Kelley Design, которая в последствие станет ядром компании IDEO, сделавшей своей официальной доктриной дизайн-мышление [2]. Сотрудники IDEO учат своих клиентов думать, как дизайнеры, чтобы улучшить качество работы. В портфолио компании разработка Palm V, первой мыши для Apple, первый ноутбук [3, 4].

Позднее идею развили учёные Стэнфордского университета и основали в 2005 году Стэнфордский институт дизайна, или d.school, который продвигает идею дизайн-мышления [5]. Своей целью институт ставит построение методов, которые позволят развить навыки креативности, применимые к самым разнообразным областям. Для этого применяемся инструмент «радикального сотрудничества», когда студентов с разных факультетов, а также преподавателей и практиков из совершенно разных областей объединяют вместе [6]. Цель такого эксперимента обеспечить многообразие точек зрения на одну и ту же проблему и привить умение смотреть на один и тот же вопрос с разных сторон.

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

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

Процесс закупки продуктов выглядит следующим образом: подразделения создают документы первичных потребностей, отражая в ERP-системе данные материалов, количества, плановую дату поступления, на основе которых в дальнейшем будет происходить списание этих продуктов. После того, как документы первичной потребности утверждены, они поступают на обработку функционала ППМ (планирование потребности в материалах). ППМ анализирует наличие потребности в материале, уже имеющиеся запасы на складах, а также будущие поступления. Как результат ППМ автоматически формирует заявки на закупку для недостающего количества. Созданные заявки служат основанием для закупки у внешнего поставщика. Более того может формироваться особый вид заявок, позволяющий выполнять перемещение с других складов компании.

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

В данной работе в качестве объекта исследования одного из таких решений выбран продукт SAP Business Integrity Screening, призванный предотвращать мошеннические действия в компании.  В статье описана краткая история разработки продукта, приведена архитектура решения, особое внимание уделено описанию фаз работы с продуктом, обозначены достоинства и недостатки, приведены примеры использования.

Рассмотрение эволюции корпоративных информационных систем целесообразно вести не столько с событийной точки зрения, сколько функциональной. Так в работе [1] предложена градация информационных систем на основе стратегического, тактического и оперативного уровней, что, собственно говоря, является классическим подходом к управлению. Данная категоризация не исчерпывает всевозможные способы деления систем [2]: существуют аналитические (OLAP), транзакционные (OLTP) и технические системы (назовем последние OLTeP).

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

Внедрение крупных программных систем подразумевает использование различных методологий имплементации, например: Accelerated SAP, Microsoft Dynamics Sure Steps или Oracle Unified Method. Прикладная методология, предлагаемая по умолчанию вендором программного продукта, детализирует одну из трех классических моделей имплементации: каскадную, итерационную или спиралевидную. Помимо этого существуют определенные правила по управлению проектами вне зависимости от его содержания, которые называют PMBoK (Project Management Body of Knowledge, свод знаний по управлению проектами) [1].

PMBoK подразумевает выделение в проекте ряда ключевых параметров, каждый из которых необходимо планировать, выполнять и осуществлять его мониторинг. Любые отклонения параметров от плановых значений требуют корректировочного действия. Свод знаний разработан американским институтом PMI и имеет длительную историю. На начало 2022 года в русскоязычной литературе доступна PMBoK шестой версии, а в англоязычной – седьмой. Каждая версия PMBoK дополняется новыми подходами, так ранее широкой огласке получили механизмы искусственного интеллекта в управлении проектами, сейчас же активно обсуждается применение принципов гибкой разработки Agile.

Для прочтения книга PMBoK весьма сложна. Определенно знакомство со сводом знаний необходимо начинать, предварительно реализовав хотя бы один проект, в противном случае вы не поймете посыл книжки. В контексте данной статьи, мы ограничимся рассмотрением ERP-проектов. Использование PMBoK в проектах имплементации корпоративных информационных систем выглядит выигрышным, по крайней мере, это позволяет структурировать характеристики проекта и вести их непрерывный контроль. Существенным упущением PMBoK является отсутствие рекомендаций по способам обработки отклонений, что противоречит циклу Деминга [2]. Вполне возможно, это было сделано сознательно, так как невозможно предложить универсальные механизмы для всех предметных областей проектов.

Одной из важных задач при имплементации корпоративных информационных систем является проектирование бизнес-процессов. Следуя [1], в ERP-проектах выделяется отдельный уровень внедрения: уровень процессов. Здесь ведется моделирование бизнес-процессов на основе общеизвестных графических нотаций, строятся модели As-Is и To-Be. Все разнообразие нотаций моделирования объединено термином CASE-средства, суть которых изначально заключалась как в проектировании, так и последующей автоматизации настроек и разработок ERP-систем [2].

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

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

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

Внедрение любой корпоративной информационной системы достаточно продолжительно по срокам и требует большого объема трудозатрат [1]. В среднем необходимо около одного года на имплементацию ERP‑системы, а трудозатраты проектной команды со стороны исполнителя обычно колеблются в диапазоне 1000–3000 человеко‑дней. Объем трудозатрат фактически задает перечень тех работ, которые обязуется выполнить интегратор для заказчика. Чем больше объем выполняемых работ, тем актуальнее становится задача по их группировке для более качественного планирования, исполнения и контроля.

Именно по этой причине в [2] выделяют уровни внедрения, такие как: процессы, приложения, данные и техника, а также управление проектом и изменениями. Однако и этого деления бывает недостаточно, так как каждый уровень по прежнему остается достаточно трудоемким. По этой причине в работах [3–4] вводится понимание концепции реализации содержания проекта, заключающейся в выделении наиболее критичных областей проекта внедрения ERP‑систем, а также предложении состава и порядка выполнения работ для каждой из областей. Примерами областей служат задачи, относящиеся к анализу, проектированию, разработке, миграции, тестированию и др.

Состав работ определяется путем рассмотрения всевозможных способов, методов и подходов, позволяющих достигнуть необходимого результата с минимальными рисками задержки продуктивного старта ERP‑системы. Объем необходимых работ дает возможность увидеть плановую потребность в человеческих ресурсах, что критично для формирования ресурсного плана проекта, а состав задач обеспечивает понимание всех тонкостей реализации предстоящего проекта. В рамках текущей статьи мы рассмотрим все критичные области ERP‑проекта и суммируем способы реализации задач каждой из областей, тем самым расширяя содержание работы [4].

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

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

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

Свод знаний по управлению проектами, широко известный как PMBoK, регламентирует множество ракурсов, в разрезе которых стоит и нужно контролировать прогресс выполнения любых проектов. Вводятся такие параметры контроля как сроки, бюджет, качества и многие другие [1]. Однако, любой продукт, получаемый по результатам проекта, должен соответствовать ожиданиям заказчика. В противном случае ожидания и реальность могут не совпасть, что полностью исключит последующие взаимоотношения с клиентом. И об этом, в PMBoK упоминается лишь вскользь. Вопрос управления ожиданиями в ERP-проектах также является весьма критичным.

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

Чтобы конечные пользователи не имели завышенных ожиданий, их ожиданиями нужно управлять. В противном случае знакомство с суровой реальностью будет весьма жестким и степень их негатива придется на фазу продуктивного запуска. Общеизвестно, что изменения, а имплементация ERP-системы относится именно к ним, достаточно критично воспринимаются сотрудниками, по крайней мере по началу [2]. Возникает очевидная потребность в качественном управлении ожиданиями, о чем мы с вами поговорим в этой статье.

В процессе внедрения модуля WM (Warehouse Management - система управления складами) системы SAP ERP может возникнуть множество вопросов, особенно если имплементация подразумевает использование функциональности единиц обработки (HU, Handling unit) [1]. Рассмотрим лишь некоторые из них: создание организационной структуры, миграция остатков при переходе к SAP ERP, переэтикетирование, обучение пользователей, использование карманных ПК и печать этикеток.