ERP-системы *

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

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

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

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

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

Здравствуйте, меня зовут Сергей Шаблыкин. Я работаю архитектором домена BI в компании «Лента». Сегодня поделюсь описанием архитектуры рассылки отчетов SAP BW, которая помогает отказаться от тяжеловесного стандартного SAP-решения и получить много дополнительных преимуществ в части экономия времени сотрудников и ресурсов Компании.

Предыстория

Мы используем SAP BW на SAP HANA уже более 10 лет. Когда-нибудь мы напишем статью об успешном импортозамещении SAP BW, но пока это время еще не пришло. За все годы у нас сложился успешный сценарий получения пользователями отчетов через рассылки: сотни пользователей получают их в определенном формате и с требуемыми фильтрами. Есть выгоды и для ИТ в целом: мы получаем меньше жалоб на производительность SAP BW, ведь без рассылки все эти сотни людей заходили бы в систему, причем примерно в одно и то же время.

С выходом SAP BW/4 вендор поменял реализацию сценария и теперь для него требуется SAP Business Objects BI Platform – мощное, но тяжеловесное решение. Так сложилось, что от этой платформы нам нужна только рассылка. Другие компоненты платформы проиграли в свое время конкурентную борьбу. Но из-за рассылок приходится ее «терпеть», в том числе все нынешние сложности с ее обновлением, поддержкой и рядом функциональных недостатков. И это становится проблемой, которая не только усложняет эксплуатацию того, что есть, но и не позволяет расширяться.

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

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

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

В статье рассмотрены примеры использования длинных (sapscript) текстов для построения шаблонов с использованием вложенности шаблонов, переменных и условных конструкций. Статья будет полезна для разработок рассылок на основе SAP NetWeaver, формирование печатных форм, рекомендательной/пояснительной документации.

Привет, это вторая статья из цикла про наш путь создания Low-Code платформы-конструктора для разработки сложных Back Office систем. В прошлой статье я сформулировал, что такое «сложные системы», задачу, которую необходимо решить, а также привел набор «наблюдений» о принципах построения IT-производства на базе Low-Code инструмента. В этот раз я опишу подход, который мы выбрали для построения Back-End и работы с базой данных. В следующих статьях про принципы организации тонкого клиента.

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

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

Обычно переход с SAP на «1C» – непростой процесс со множеством подводных камней. И не только потому, что сама по себе миграция – комплексный проект, а корректный перенос данных и бизнес-процессов требует усилий и времени. Часто заказчики сталкиваются с отсутствием в новой системе привычных возможностей. Однако с надежным технологическим партнером реализовать их в российской ERP-системе возможно.

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

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

Привет, я расскажу про наш путь создания low-code платформы-конструктора для разработки сложных Back office систем. Сложными, в данном контексте, называются продукты с базами данных на 500 таблиц и больше, тысячами web-экранов для пользователей, большим кол-вом логики в бизнес процессах, постоянным потоком новых требований и оказанием поддержки сотням клиентов. Платформой-конструктором я называю именно полноценный инструмент для создания новых (!) продуктов с нуля, а не готовый продукт с небольшими возможностями по кастомизации. Я опишу подробно историю создания нашего решения, какие подводные камни мы встретили на своем пути, и какие подходы для нас сработали лучше всего. Статья может оказаться особенно полезной для среды Финтех.

Внедрение практически любой корпоративной информационной системы требует ее доработки для реализации как законодательных, так и специфических требований предприятия. Согласно [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]. Цель такого эксперимента обеспечить многообразие точек зрения на одну и ту же проблему и привить умение смотреть на один и тот же вопрос с разных сторон.

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

В данной статье посмотрим некоторые часто встречающиеся приёмы, а также посмотрим наличие к ним стандартной документации (справка тут Auding and Logging). В данной статье будут рассмотрены прежде всего стандартные инструменты.

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

Процесс закупки продуктов выглядит следующим образом: подразделения создают документы первичных потребностей, отражая в 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, призванный предотвращать мошеннические действия в компании.  В статье описана краткая история разработки продукта, приведена архитектура решения, особое внимание уделено описанию фаз работы с продуктом, обозначены достоинства и недостатки, приведены примеры использования.

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