Привет, это вторая статья из цикла про наш путь создания 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, призванный предотвращать мошеннические действия в компании. В статье описана краткая история разработки продукта, приведена архитектура решения, особое внимание уделено описанию фаз работы с продуктом, обозначены достоинства и недостатки, приведены примеры использования.
В данной статье рассмотрим, как настроить и использовать бонусную программу лояльности, а также рассмотрим отчеты, с помощью которых можно проанализировать остатки и движение бонусных баллов.
В данной статье продолжим обзор функциональных возможностей программы 1С:ЕРП в части использования скидок. Рассмотрим функциональную опцию по использованию дисконтных карт лояльности, а также отчеты, с помощью которых можно анализировать предоставленные скидки.
Привет, Хабр! Меня зовут Анастасия Валеева, я – руководитель группы обеспечения качества в Tele2. Наша команда работает в большинстве своём с SAP ERP, и мы не понаслышке знаем, что автоматизация данной платформы — дело далеко не тривиальное. В этой статье я хочу поделиться с вами, как и зачем мы автоматизировали тестирование с помощью Python.
Рассмотрение эволюции корпоративных информационных систем целесообразно вести не столько с событийной точки зрения, сколько функциональной. Так в работе [1] предложена градация информационных систем на основе стратегического, тактического и оперативного уровней, что, собственно говоря, является классическим подходом к управлению. Данная категоризация не исчерпывает всевозможные способы деления систем [2]: существуют аналитические (OLAP), транзакционные (OLTP) и технические системы (назовем последние OLTeP).
Следует прояснить, что собой представляет корпоративная информационная система, информационная система и стандарт. Начнем с последнего, под стандартом понимается определенная стратегия управления предприятием, целью которой является оптимизация процессов и сокращение затрат. В виду этого, информационная система будет представлять собой специализированное программное обеспечение, реализующее стандарт в заданной предметной области компании. И, наконец, корпоративная информационная система есть совокупность информационных систем, работающая в масштабе как всего предприятия, так и возможного холдинга.
Итак, суть проблемы: если на предприятии необходимо ограничить права пользователей в разрезе подразделений, то типовой механизм, реализованный в «1С:ЗУП КОРП», нам не поможет, так как полноценное ограничение доступа по подразделениям в программе не поддерживается, и на данный момент ограничения доступа по подразделениям распространяются только на штатное расписание.
Многие компании задаются вопросом: как увеличить продажи и привлечь больше клиентов? Одним из самых эффективных методов является правильное применение скидок при продажах.
В данной статье рассмотрим, как функционал использования скидок в программе 1С Управление предприятием ЕРП 2.5.
