ERP-системы *

В данной статье мы рассмотрим заключительные этапы работы казначейства в 1С:ERP: выгрузку платежных поручений в клиент-банк и загрузку полученной банковской выписки.

Привет! Меня зовут Дима Татаринов, я занимаюсь бэкенд-разработкой в К2Тех. Мы живем в эпоху «великого переселения» СУБД с SQL Server, IBM DB2 и Oracle на отечественную СУБД Postgres Professional или аналоги. Подобные проекты «паровозиком» цепляют за собой потребность в модернизации бизнес-приложений, которые на них работали. Ранее зарубежные производители накладывали сильный вендор-лок с помощью экосистемы своих инструментов: от специализированного языка написания бизнес-логики (PL/SQL для Oracle) до сервера приложений. Именно поэтому особенно злободневной становится старая шутка про Oracle - «Oracle doesn't have clients. It has hostages» (У Oracle нет клиентов. Есть только заложники). 

Цена освобождения уже стала известна российским вендорам прикладного ПО, которые реализовали в своих продуктах миграцию на отечественные СУБД. Но что делать с тысячами так называемых «учетных систем», которые используют компании на момент принятия решения о миграции. Понятно, что затрат не избежать, но как сделать их предсказуемыми и не получить новый «вендор-лок» взамен старого?  

С таким запросом к нам стали часто обращаться корпоративные заказчики, и мы решили посмотреть на предложения вендоров в этом сегменте. 

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

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

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

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

Привет, Хабр! Меня зовут Анастасия Валеева, я – руководитель группы обеспечения качества в Tele2. Наша команда работает в большинстве своём с SAP ERP, и мы не понаслышке знаем, что автоматизация данной платформы — дело далеко не тривиальное. В этой статье я хочу поделиться с вами, как и зачем мы автоматизировали тестирование с помощью Python.

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

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

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

Многие компании задаются вопросом: как увеличить продажи и привлечь больше клиентов? Одним из самых эффективных методов является правильное применение скидок при продажах.

В данной статье рассмотрим, как функционал использования скидок в программе 1С Управление предприятием ЕРП 2.5.

Внедрение крупных программных систем подразумевает использование различных методологий имплементации, например: 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].

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

GTT – global temporary tables, таблицы которые наполняются и очищаются в рамках ABAP-сессии (application session), но находятся при этом на уровне БД (то есть данные не передаются между Database и Application).

GTT могут помочь сделать код по выборке из БД более удобочитаемым, а также сократить количество передаваемых данных между DataBase и Application.

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

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

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

ERP (enterprise resource planning) — это планирование ресурсов предприятия. В наиболее общем виде ERP можно определить как совокупность всех базовых бизнес-процессов, необходимых для управления компанией: финансы, управление персоналом, производство, цепочка поставок, услуги, закупки и многое другое. На самом базовом уровне ERP помогает эффективно управлять всеми этими процессами в интегрированной системе. 

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

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

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

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

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

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

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

Одним из немногих функционалов информационной системы, выносимых в отдельный подпроект внедрения, является планирование потребностей в материалах (Material Requirement Planning, далее – MRP) [1]. Существуют различные типы MRP в зависимости от вида производства и сложности планирования: планирование на основе потребления, планирование по точке перезаказа (Reorder Point, далее – ROP), сезонное планирование и др.

Простейшим видом MRP является планирование по точке перезаказа (Reorder Point - ROP). Суть ROP сводится к измерению параметров, характеризующих состояние склада: текущий уровень запаса продукции и значение точки перезаказа для неё. Если значение точки перезаказа превышает текущий уровень запаса, запускается процедура пополнения продукции за счёт внутреннего производства или закупки у внешнего поставщика (рис. 1). Внедрение ROP в стандарте ERP (Enterprise Resource Planning) пророчит сложности [2]. В частности:

Российский рынок ERP-систем сильно изменился за последние два года. За это время страну покинули крупнейшие западные вендоры — Oracle, SAP, Microsoft. 

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