ERP-системы *

Чем хорош малый бизнес, особенно на своем старте? Ему не нужны сложные инструменты: он в состоянии увидеть состояние дел расчетами «на коленке», а план действий уместить карандашом на трамвайном билетике.

А когда бизнес подрастает? Скажем, его месячная выручка становится 100М+, количество сотрудников исчисляется сотнями, а бизнес-процессы усложняются настолько, что перестают быть прозрачными, покрываются «туманом войны».

Эта история про то, как инструмент, понравившийся команде на старте бизнеса, довел её до убытков в десятки миллионов при росте оборотов, когда компания стала крупнее. И как прозрачность вернула контроль и разблокировала рост выручки на 50%.

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

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

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

Объёмный план затрагивает весь производственный цикл: от закупки сырья и управления запасами до отгрузки продукции клиентам и, конечно, включает производство. Все должно быть согласованно, четко подогнано одно к другому и работать как часы. Без крутой ИТ-системы здесь не обойтись.

С 2016 года мы пользовались зарубежным софтом, но система устарела, а обновления стали недоступны. Нам предстояли муки выбора российского решения, инженерные компромиссы и кастомизация. И тут мы первыми в России рискнули сделать ставку на систему объемного планирования In.Plan. Только вот нюанс: решение было облачным, а нам был нужен крепкий on-premise прямо в нашей промышленной инфраструктуре, ну и других требований к кастомизации было миллион.

Недавно к нам в компанию взяли нового сотрудника на должность программист или разработчик MS Dynamics AX 2012 (для начала выбрали версию 2012, но с перспективой его быстрого переключения на любые версии, включая D365 FO) — стажёр Воякс Иван Иванович (он же Woyax).

В этой статье:

Технология создания ИИ-помощника для работы с 1С:ERP.

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

И почему та же самая документация 1С, при правильной обработке, способна превратить ИИ в супер-помощника – то есть многократно его усилить.

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

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

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

Вообще-то мы делаем конструктор корпоративных баз данных с автоматизациями, но меня давно просили сделать какой-нибудь демонстрационно-учебный проект — чтобы, типа, best practice можно было глянуть. Так как ИИ бесжалостно прёт изо всех щелей и от него никуда не деться, решили сделать такой, чтобы использовал его, но только, блин, с реальной пользой, а не очередное «напиши статью про то — не знаю что». Получилось хорошо: по задаче работает лучше, чем если бы мы человека за разумные деньги посадили делать то же самое. Ну и, понятно, быстрее (хотя с последними замедлениями API OpenAI хотелось бы ещё побыстрее).

Итак, задача: есть у нас, например, небольшой завод — и покупает он там всякое разное: болты, винты, пузырьки, доски, пропановые баллоны и так далее. Есть поставщики, присылают счёта. Счета эти даже кто-то из начальства, возможно, проверяет за кладовщиком. Если проверять хорошо, то это вообще куча времени уходит — и было бы здорово...

Художественная реконструкция реального эпизода 1773 года: охота за султанскими сокровищами в Средиземном море.

Главный герой — Георгий Ризо, греческий капитан, адъютант графа Алексея Орлова и командир корсарской эскадры. Перед ним — карта района плавания. По ней он объясняет экипажу свой замысел и вдохновляет экипаж на рискованное предприятие.

Бизнес — это тоже своего рода поход за сокровищами.

И в такой мощной программе управления, как 1С:ERP, «карта похода» — единый наглядный инструмент планирования — нужна руководителю ровно так же, как капитану — карта района плавания.

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

Ниже — о том, как я создавал прототип такой карты. Создавал буквально «на коленке». И как из «карты для руководителя» неожиданно вырос ИИ-помощник по планированию в 1С:ERP.

Привет, Хабр! Меня зовут Александр Любин, я архитектор 1С в CDEK. В этой статье расскажу про наш опыт интеграции 1С в ERP‑систему и личный кабинет. Расскажу, с какими проблемами мы сталкивались, как их решали, какие инструменты использовали. 

Мой опыт в разработке — 15 лет. Последние три с половиной года — в CDEK.За это время мы с командой смогли в корне изменить позиционирование 1C в компании от «что‑то там для бухгалтерии» до фундамента финансового, регламентированного и оперативного учёта. Смогли доказать, что 1C может быть средой быстрой разработки и инструментом, который позволяет обеспечить потребности как фронт, так и бэк контуров. Я расскажу, как у нас всё проходило.

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

Корпоративные информационные системы позволяют автоматизировать набор бизнес-процессов. Чем больше процессов, тем представительнее стандарт, цифровизирующий их. Так наиболее известным и востребованным классом систем является ERP [2]. ERP-системы охватывают практические все административно-хозяйственные операции компании и представляют средства для их автоматизации. Помимо ERP доступен широкий набор прочих классов: MRP, TMS, WMS, APS, BI, MES и др. Если раньше идея объединить все стандарты в единый класс казалась обоснованной, то на текущий момент – это утопия, так как слишком стремительно развиваются технологии и появляются новые виды систем.

Потребность в управлении различными классами программных систем, являющихся основой функционирования современного предприятия, становится все более востребованной и незаменимой: достижение стратегических целей компании тесно связано с вопросом цифровизации бизнес-процессов. Среди множества сводов знаний, применимых к информационным системам: PMBoK, BABoK, BPM CBoK, DAMA-DMBoK, EABoK/TOGAF, SWEBoK, ITIL [3-9], последние два являются наиболее релевантными тематике данной статьи. Свод знаний по программной инженерии, SWEBoK, охватывает весь жизненный цикл информационной системы, в то время как лучшие практики по управлению ИТ-услугами, заданные в ITIL, не ограничиваются рассмотрением только софтверных решений, а представляют все многообразие ИТ-продуктов.

Меня зовут Алексей, я скорее инженер, чем разработчик. Занимался производствами, конструировал приборы и в какой-то момент решил попробовать сделать универсальный конструктор для учёта всего, что мне было нужно на производстве — материалов, заказов, процессов, планирования сроков и т.п.

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

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

В общем, начитавшись всей этой чуши, поставили MIT, залили на GitHub, написали статью на Хабр — и... получили поток комментариев: «Ваш код — УГ» и «Всё надо переделать на Laravel».

В итоге, потратив охулиард нервных клеток и набрав 900 звездочек на GitHub, я бросил это опенсорсное занятие и поставил самые обыкновенные платные лицензии.

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

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

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

С помощью электронного документооборота физические лица могут получать госуслуги, устраиваться на работу, поступать в ВУЗ, оформлять кредиты, не выходя из дома. Организациям данный механизм позволяет сокращать издержки, связанные с созданием, обработкой и пересылкой документов. Электронный документооборот ускоряет и упрощает процесс обмена документами между компаниями и государственными органами. Более того, подключение к системам ЭДО сейчас нужно не только для удобства, но и в отдельных случаях является необходимостью: некоторыми документами можно обмениваться только в электронном виде. Системы ЭДО требуется для работы с маркированными товарами, прослеживаемостью, маркетплейсами и электронными торговыми площадками, для сдачи отчетности в ФНС и в другие государственные структуры.

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

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

История началась в далеком 2016 году, когда у меня был небольшой свечной заводик. Не свечной, конечно, но все же производство — и нужно мне было на нем сделать автоматизацию. Чтобы компоненты закупались вовремя, списывались со склада в правильном количестве и автоматически планировалось, какие операции делать в рамках рабочего дня. Тогда я впервые подумал, что неплохо бы иметь программируемый конструктор — что-то типа MS Access, но только в web и чтобы логика и запросы программировались одинаково и понятно.

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

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

Однако сегодняшнем материале мы посмотрим на open source-подход с прикладной точки зрения. Делюсь продолжением разговора на эту тему с Михаилом Скворцовым, основателем MK.Lab и сопредседателем консорциума Rudoo, а также Сергеем Коробковым, соучредителем ИнфЦентрПроект и КиржачТелеком.

Недавно у меня был небольшой спор с экономистом клиента. Речь шла о том, как понять — сколько должно стоить изделие. Экономист утверждал, что чем тяжелее по весу изделия или, чем дороже материалы, тем оно должно быть дороже. Я же утверждаю, что стоимость изделия никак не связана с весом или стоимостью материалов, а связана с узким местом компании.

Итак, у нас две принципиальные ситуации с ценообразованием.

Привет, Хаброжители! Сегодня мы делимся с Вами переводом статьи о распределенном монолите.

Аннотация
Привлекательность микросервисов — гибкость, масштабируемость, отказоустойчивость — часто ведет организации по пути, полному непредвиденных опасностей. В этой статье раскрывается обманчивая архитектурная ловушка: распределенный монолит. То, что начинается как, казалось бы, разумный паттерн проектирования для отделения бизнес-логики от технических проблем путем централизации «основного домена», незаметно превращается в антипаттерн, который сводит на нет все преимущества, обещанные микросервисами.

Мы подробно описываем коварные симптомы: кошмары версионирования, паралич развертывания и эрозия автономии команды. На ярком примере из реальной жизни — системе «Drive» и доставки на дом Carrefour — мы раскрываем основную проблему: внутреннюю модель, удерживаемую внешними стандартами. Затем мы раскрываем освобождающие решения: принятие по-настоящему нативных бизнес-моделей и разрыв цепей общих «основных» библиотек кода в пользу явного промежуточного программного обеспечения и надежных API-контрактов. Это путь не только к коду, но и к возвращению обещаний микросервисов.

Внедренный программный продукт подлежит дальнейшему развитию, причин для которого достаточно: изменение законодательства, технологические тренды и новинки, цифровизация не автоматизированных областей и др. Часто подобные активности над ИТ‑системами связывают с запросами на изменение (ЗНИ), относящимися к процессу управления изменениями. Это действительно так, однако работа с ЗНИ требует выстраивания регулярных бизнес‑процессов, вовлекающих как бизнес‑пользователей, так и технических специалистов, обеспечивающих надзор над корпоративной архитектурой предприятия и соблюдение целостности существующих ИТ‑сервисов. Для чего согласно EABoK [4] организуются следующие организационные сущности: