Erp-системы

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

Немного истории

Четыре года назад для нужд нашей организации было принято решение написать мобильное приложение для двух платформ (iOS и Android). Программист был один, а опыта работы с нативными языками на тот момент не было. Для этих целей мы решили попробовать кроссплатформенную схему разработки от Cordova.

Выбор фреймворка

Оказалось, что реализовать проект в основе которого лежит один подход, можно по-разному. Выбрав Phonegap можно было получить платформу Cordova, плюс несколько полезных инструментов для отладки и демонстрации приложения, а главное, облачную сборку для разных платформ (не бесплатно). Для тех кто не в курсе, приложения для iOS собираются только на macOS, а для Android, можно собирать как на macOS, так и на Windows. Судя по всему идея заработать на облачной сборке у Phonegap провалилась, так как Adobe прекратила инвестиции в проект. Другой путь это Ionic, команда этой группы предлагает набор инструментов охватывающий все этапы разработки гибридного приложения от А до Я. Здесь к платформе Cordova вы получите возможность интеграции с популярными фреймворками (Angular, React, Vue), инструменты для бесплатной и платной разработки, подробную документацию и многое другое. Мы пошли по пути наименьшей зависимости от кого бы то ни было. Взяли Cordova, а в качестве фреймворка для single page application выбрали менее хайповый, но довольно симпатичный Framework 7 (так же были доступны Angular, React, Vue и другие). В реальном проекте трудности обычно возникают либо с плагинами, либо с особенностями самих платформ. Так как команда Ionic предлагает готовые решения известных проблем, многим, будет легче поддерживать проект присоединившись к ним.

Плюсы и минусы

После нескольких лет работы с платформой могу выделить некоторые значимые плюсы и минусы. Далее в данной статье буду говорить о некоторых пунктах подробнее.

Плюсы:

• не нужен программист для каждой платформы на начальном этапе

• лёгкая интеграция с приложениями имеющими веб интерфейс

• разнообразие фреймворков для разработки одностраничных приложений

• возможность обновлять код без выпуска новых сборок

• возможность использования большого количества бесплатных веб компонентов

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

Минусы

• поддержка существующих плагинов

• особенности браузерных компонентов webview

• неудобная работа с файловой системой

• многозвенная схема отладки приложения

• вечно-зеленый компонент webview у Android

Программисты и плагины

На начальном этапе можно действительно обойтись без навыков нативной разработки, но по мере увеличения количества плагинов в вашем проекте, это будет неизбежно. Дело в том, что код плагинов быстро устаревает и часть функционала либо перестает работать, либо будет работать неправильно в определенных версиях ОС той или иной платформы. Бывают ситуации и хуже. Так обновленный Xcode поддерживающий последнюю версию платформы iOS, может отказаться собирать ваш проект, обнаружив в нем плагин написанный на предыдущей версии swift. Пример конечно экзотичен, потому как 99% плагинов под iOS написаны на Objective C, тем не менее, с этим приходилось сталкиваться. Немалое количество плагинов сообщество энтузиастов-разработчиков забросило, а те что поддерживаются, порой ждут обновлений довольно долго. Так же, нужного плагина может и не быть вовсе. В итоге, чтобы иметь актуальный и работающий проект, вам необходимо будет вносить изменения в нативный код плагинов, писать их с нуля или просто редактировать главные модули приложения (на Objective C и Java соответственно).

Интеграции

Интегрировать в проект отдельные элементы веб приложений или полноценные приложения довольно удобно. Ваш проект работает в браузере, а это значит, что вы сможете загружать в него веб страницы, делать запросы к веб сервисам, использовать возможности WebDAV и многое другое. При HTTP запросах из вашего приложения к другим веб ресурсам, вы наверняка столкнётесь с проблемами аутентификации, CORS ограничениями, нюансами работы с сертификатами итд. Полноценные веб приложения лучше загружать в отдельный браузерный компонент с помощью плагина. Если потребуется, вы даже сможете настроить обмен данными между вашим основным браузерным компонентом (webview) и внешним. При этом, пользователь не будет покидать окна мобильного приложения. Как показала практика, многие десктопные приложения уже имеют веб интерфейсы, а некоторые из них, даже адаптированы к мобильным телефонам и планшетам. Так, например, мне удалось интегрировать веб версии клиентов MS Outlook, 1С, Redmine. Конечно, там не все гладко, неоднородность интерфейсов, отсутствие поддержки touch экранов, ограничения при работе с файловой системой и другие нюансы. Но спектр возможностей от таких интеграции, по-моему, перевешивает все недостатки.

WebView

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

VPN

При работе с корпоративными удаленными ресурсами (веб приложения, сервисы, базы данных), которые не являются публичными, возможно, придётся использовать VPN. Такой подход является довольно логичным, но затея не является безобидной. В реальности это накладные расходы на разработку и обслуживание, плюс негативный опыт ваших пользователей. Идеальным решением будет интеграция VPN клиента в приложение, что тоже не просто. Так, например, библиотеку с открытым кодом Open VPN можно интегрировать в проект с помощью нативного кода и предварительно скомпилированных библиотек. Плагина для Cordova нет, возможно, появится позже. Здесь так же придется немного помучиться с приложениями и сервисами работающими по протоколу HTTPS. Дело в том, что последние в корпоративной среде используют либо самоподписанные сертификаты, либо сертификаты выданные локальным центром сертификации, что для ваших webview не являются доверенными. Этот вопрос решается для двух платформ, но универсального и однозначного подхода здесь нет. Кто-то считает, что доступ к ресурсам внутри сети может быть осуществлен по-обычному HTTP. В этом есть логика, но не надо забывать, что весь трафик в данном случае будет передан без шифрования. Можно научить приложения для iOS и Android работать по HTTPS с ресурсами внутри сети и такой вариант считаю предпочтительным.

Провайдер сервер за прокси

Реализация такого сервера задача необходимая, если конечно, ваше приложение собирается получать push-уведомления. Для работы с APNS (служба Push-уведомлений Apple), потребуется установка соединения только по протоколу HTTP v.2 + TLS. Библиотеки и API популярных серверов научились работать с HTTP2, но не все они умеют работать с прокси серверами и здесь, возможно, будут сложности. Я какое-то время для этих целей использовал Apache, позже перешёл на собственный сервер, который был написан на Nodejs. Это оказалось невероятно просто и удобно. FCM для Android в этом смысле не такой требовательный (работает на HTTP v.1), при работе с ним проблем не наблюдалось.

Распространение приложений

Для iOS приложений придется оплачивать ежегодную enterprise лицензию, для Android это бесплатно. Плюсом enterprise лицензии для iOS является отсутствие модерации кода и возможность свободного распространения приложения без App Store. Достаточно иметь публичный сервер на котором у вас будут файл приложения и файл манифеста. Ссылку на манифест в специальном формате вы и будете распространять среди новых пользователей вашей организации. У Android приложений ограничений в распространении нет изначально. Последние рекомендую распространять через стандартные магазины приложений, так как APK загруженные не из магазина, по умолчанию, не являются доверенными для ОС Android.

Заключение

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

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

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

Здравствуйте, я Сергей. Мне запрещают разговаривать с клиентами. Но я в этом не виноват.

Кто такой?

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

Работал во всяких местах, лет 15-20, в основном на заводах. И программистом, и начальником программистов, и ИТ-директором. Знает автоматизацию бизнеса вдоль и поперёк, потому что долго сидел внутри и делал эту самую автоматизацию каждый день. Много работал с директорами, собственниками, подрядчиками, разными платформами и решениями. Большой специалист по эксплуатации и развитию систем. И зачем-то попёрся, на старости лет, во франч.

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

Первый обет молчания

У начальства были опасения, справится или нет. Как известно, заводских программистов обычно считают ленивыми толстозадыми упырями, которые только и умеют, что в носу ковыряться. А тут новые современные продукты, постоянное развитие, драйв, ещё какие-то слова, которые на собеседовании сказали. Сергей сказал, что справится, на том и порешили.

Первую неделю к Сергею все присматривались. В первую очередь, из-за возраста ему уже под 40, а вокруг одни хипстеры. Дали одну задачу сделал. Вторую тоже. Быстро, красиво, сдал с первого раза. Вроде начало получаться, все ограничения были убраны: Серёга наш чувак. Никакого поводка.

И тут повезло обратился клиент с проблемой и программным продуктом, с которыми Сергей хорошо знаком ещё с завода. Устроили скайп, послушали, обсудили. Раздался первый звоночек Сергей попросил сначала базу посмотреть, типа аудит сделать. Вообще, так не принято было, и все собравшиеся испытали смешанные чувства радость и опасение. Клиент согласился.

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

Клиент расстроился. Менеджер расстроился. Начальник Сергея расстроился. Сергей только не расстроился думал, что здорово помог людям. Клиент ушёл думать. В тот же день позвонил менеджеру и сказал, что не будет работать с такой компанией.

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

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

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

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

Первая индульгенция

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

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

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

Появились ещё несколько клиентов, на разговор с которыми отправляли Сергея лично или через средства связи. Определённые уроки Сергей всё-таки извлёк, и втихаря стал более вежливым перестал тыкать клиента носом в его позорный учёт, просто невзначай упоминал, что есть ряд проблем, которые Сергей тоже может решить. Эта ненавязчивость была воспринята очень хорошо, и пресейлы с участием Сергея стали быстро превращаться в сейлы. Но пришла беда, откуда не ждали.

Поговорив с несколькими клиентами, Сергей всем им продал какие-то работы. И вот настал момент, когда эти работы надо делать. Как положено, все одновременно, срочно, важно и вы же обещали.

Второй обет

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

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

Чисто теоретически, наверное, можно было бы декомпозировать эти работы между аналитиками, разработчиками и консультантами, если бы не парочка трудностей. Во-первых, декомпозиция работы стоила дороже, чем сама работа (словами Сергея это им сначала целый мир объяснить надо). Во-вторых, эту декомпозицию мог сделать только сам Сергей (т.е. проблема нехватки времени Сергея не решилась бы, а лишь усугубилась). В-третьих, клиенту-то как объяснить увеличение стоимости работ в 2-3 раза?

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

Пресейлы

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

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

Сели, подумали, и решили, что виноват всё равно Сергей. Слишком велика разница между тем, что и как говорит клиенту Сергей, и что на другой день повторяют руководители проектов. Наверное, Сергей какую-то чушь несёт, отчего клиент радуется, а когда ему нормально озвучивают - почему-то отваливается.

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

Новый виток

Сергей вспомнил, чему его учили собственники бизнесов, в которых он работал нишу искать. Голубой океан, а не в красный лезть. Подумал денёк, и понял надо заниматься сопровождением. Да и начальство к тому же выводу пришло.

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

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

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

Менеджеры в той компании, в принципе, люди несчастные. Они не знают ни бизнеса, ни продукта, не понимают ни слова из задачи, не разбираются в квалификации специалистов (поэтому каждый раз вынуждены давать полный круг по офису, чтобы найти исполнителя). А получают процент с продаж.

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

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

И опять

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

Менеджерам-то всё нравилось, а вот их начальнику нет. И тому, что над продавцами и программистами тоже. Главный продавец быстро понял, к чему идёт менеджер, в общем-то, не нужен таким клиентам. По сути, он просто принёс Сергею лид. За лид, вроде, правильно один раз заплатить, а не отстёгивать каждый месяц. Та же мысль пришла в голову главному начальнику зачем держать менеджера, платить ему деньги, если работа программистов и клиента ведётся напрямую?

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

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

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

Новая надежда

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

Ну и договорился. Наделил их очень важными обязанностями, типа организации встреч и переговоров, отслеживания исполнения задач, разговоров по несвязанным с задачами поводам и т.д. И не просто попросил делать всё это сказал, что сам никогда всего этого делать не будет, ни при каких обстоятельствах. А делать-то надо. Вот и острая необходимость в менеджере. Ну и начали работать.

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

Но, как мы помним, Сергей взял только двух менеджеров, а тринадцать остались, где были. Сергей с ними тупо не работал так, по мелочи, разовые задачи брал для стажёров. Появилось неравенство среди менеджеров. Причём, не связанное с клиентами или личными заслугами менеджера. Единственным критерием успеха была работа с Сергеем и его командой.

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

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

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

Вообще дичь какая-то

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

Сергей подумал и решил, что будет сам их растить. Пусть нанимаются и числятся они в другом отделе, он просто выберет одного человека, подпустит к своей команде, всё объяснит и будет новому менеджеру помогать стать профессионалом. Так и сделал.

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

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

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

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

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

Оставил одну лазейку электронная почта. И, вроде, пока держится. Менеджеры привыкли, и пытаются уже не чаще раза в месяц.

Иногда в интерфейсе наших приложений СБИС возникаетнеобходимость "сгруппировать" часть записейв некотором списке (например, служебные сообщения в чате, контакты и телефонные звонки).

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

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

Постановка задачи

У нас есть два сервиса. Как бы может быть и больше, но, следуя предыдущей картинке, пусть для определенности это будутсервисы Звонков и Контактов.

Спасибо коллегам из CRM за интересную задачу.

Хотим в карточке организациив сквозном хронологическом порядкепо дате выводить контакты и звонки, но все звонки между соседними записями контактов"схлопнуть" в единственную записьс указанием их количества.

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

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

• PostgreSQL Antipatterns: ударим словарем по тяжелому JOIN

• PostgreSQL Antipatterns: навигация по реестру

• SQL HowTo: пишем while-цикл прямо в запросе, или Элементарная трехходовка

Неудачное решение #1: "дай мне все"

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

Да и для сервиса задача "отдать все" совсем нелегка, если там данных за несколько лет работы. Но зачем нам "все", если пользовательдальше первой страницы листает очень редко?

Неудачное решение #2: "частый гребень"

Так, нам контакты группировать не надо?.. Давайте тогдазапросим первую страницу (20 записей) с сервиса контактов, адля каждого интерваладат между "соседними" контактами спросим, что там есть в звонках - сразу и количество получим.

А теперь давайте представим, что у нас все звонки (или очень много) оказались хронологически "над" первым же контактом - что будет? Абудут те же самые тормоза в интерфейсе, что и в предыдущем варианте.

Кроме того, мы илиотправим на сервис много запросов(на каждый из интервалов), чем создадим избыточную нагрузку. Или отправимодин запрос со списком всех интервалов, но он заведомо будет отрабатывать "долго".

Удачное решение #1: "чтение сегментами"

Набив шишек на предыдущих решениях, приходим к выводу, что нам надозапрашивать данные у обоих сервисов по курсору- сколько-то записей (пусть будет 20), начиная с какого-то индексного ключа.

Что дальше делать с двумяупорядоченными сегментамиданных, достаточно очевидно - сливаем (merge ordered) и отрезаем (limit) от упорядоченного все записи после ближайшего из "крайних" ключей от каждого из сервисов.

Например, в нашем примере получилось, что ключ времени "крайнего" звонка соответствует только 15 из 20 прочитанных контактов. Про порядок оставшихся 5 контактов и других звонков мы не можем ничего сказать, потому что "других звонков" как раз нету в обозримом пространстве - поэтомунарисовать их пока не можем.

Неудачное решение #3: "One Ring to rule them all"

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

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

Неудачное решение #4: "два ключа на server-side"

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

Поскольку у насstateless server-side БЛ, то либо мы их таки и не сохраним, или вынуждены будем городить где-тоотдельное хранилище состояний. Сделать это можно, но совсем не просто:

• хранение сегментов должно происходить по уникальномуключу экземпляра-выборки-на-странице

• необходимаполитика инвалидацииэтих данных со временем, чтобы память не "текла"

• работа с этим хранилищем подразумеваетдополнительные издержки на сериализацию-пересылку-десериализацию

Удачное решение #2: "два ключа на client-side"

Собственно, а зачем нам уносить все это на сервер-сайд, если вседанные нам нужны только на клиенте?.. Давайте их там и оставим.

То есть ровно теданные, которые "не отрисовали" оставить хранитьсяна клиенте (например, прямо в памяти вкладки, даже не в localStorage), пока нам не понадобится их нарисовать.

В нашем предыдущем примере получится что-то вроде:

• прочитали параллельно 20 контактов и 20 звонков

• звонки "сгруппировали" в 5 записей

• нарисовали 5 "групповых" звонков + 15 контактов

• 5 ненарисованных конктактов оставили в хранилище

• до 20 чего-то не хватает? запрашиваем! (контакты и звонки по 20, параллельно от своих "крайних" ключей)

• "задача сведена к предыдущей", только у нас уже сразу 25 контактов на 20 звонков есть

Edge Cases

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

К счастью, такая ситуация достаточнопозитивно воспринимается в интерфейсе, поскольку мы показываем пользователю: "Эй, все хорошо, мы не умерли, не повисли, мы работаем!"

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

Но мы круче. В определённых условиях мы умеем надувать огромные перламутровые пузыри, которые потом годами не лопаются. Толку от них нет, но Красиво же!

Проекты автоматизации

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

Как ни стараются agile-цыгане, но проекты автоматизации до сих пор делаются по старинке каскад, водопад, PMBOK. Гибкие методы применяются лишь там, где не страшно ошибиться. А проект стоимостью в несколько миллионов хочется контролировать.

Пузырь растёт с самого начала проекта обследования, моделирования, написания ТЗ. Заказчик делает вид, что знает, чего ему надо. Интегратор делает вид, что не замечает, что заказчик делает вид. Все умные, толковые, деловитые и вежливые. А пузырь растёт.

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

Тут подключаются главные надуватели программисты. Берут ТЗ и фигачат. Наше дело маленькое сделать то, что написано. Правильно написано, или чушь какая-то мы причём? Пузырь, вместе с затратами, растёт очень быстро.

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

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

Тут пузырь и обнаруживается. Сделано не то и не так. Потому что спроектировано не то и не так. Потому что заказчик не то сказал Или аналитики не так поняли Или программисты не так сделали Ну, вы сами знаете, как это бывает.

Но пузырь лопается редко. Слишком он прекрасен.

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

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

А пузырь стоит.

Корпоративные сайты

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

Дальше от исполнителей, т.е. создавателей сайта, уже ничего не зависит. Как бы они ни старались, в большинстве случаев построят пузырь. Собственно, пузырь им и заказали. Просто называется он корпоративный сайт.

Подрядчик, по сути, балансирует между двумя стратегиями.

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

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

Но пузырь, скорее всего, останется. Интернет полон таких произведений искусства. До очередного умника на совещании, который скажет нам точно нужен новый сайт!.

Внутренняя автоматизация

Это сфера, созданная именно для надувания пузырей. Особенно, если внутри компании работают программисты с выдумкой и амбициями.

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

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

Программисты придумывают себе задачи сами. Одновременно живут два потока всякая мелочёвка для поддержания существования системы, и Большая Разработка Пузырей. Сваяет программист какую-нибудь крутую систему, по собственному разумению, отладит, насладится и Фифти-фифти.

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

А потом произойдёт сюжет, из которого жалобные статьи появляются. Не прижилось, Компания оказалась не готова, Я опередил завод в развитии, Меня никто не понимает и т.д. Но пузырь остаётся.

Кто продавать не умеет или не хочет просто оставляет пузырь стоять на месте. Я часто смотрю на системы, в которых местные программисты много лет надували пузыри и, поверьте на слово, получаю истинное удовольствие.

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

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

Да, вы правильно поняли. Я тоже пузыри надуваю иногда. Сказать директору завода в деревне создавай и поддерживай среду для самореализации людей Прям Тони Роббинс в фуфайке.

Вступление

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

О чем это?

Начну с частного примера. Представьте себе что ты - собственник компании. Ты считаешь что у тебя есть и ERP и CRM (эта эротическая фантазия может возникнуть, например, из-за наличия у тебя BAS ERP).
И вдруг тебе в голову приходит замечательная управленческая инициатива: персонально связываться с регулярными клиентами, которые перестали у тебя покупать: звонить, выявлять причину отказа и оперативно возобновлять сотрудничество.
Для этого у тебя есть много вариантов реализации. Позволь я назову их не-ERPшными вариантами.

Например, ты можешь попросить своего ИТшника сделать отчет. Очень простенький отчет типа отобрать клиента с признаком РЕГУЛЯРНЙ, у которого за последние 60 дней продажи равны 0.
Но есть проблема. Ты этот отчет запустишь только один раз - когда твой ИТшник будет сдавать работу. Ты его похвалишь, подпишешь акт - и забудешь. Отчет потеряется в дебрях встроенных менюшек. Отчеты - Сервисные - Дополнительные - Для руководства - Клиентские - Не покупающие. Я знаю о чем говорю. Моей команде часто заказывают уникальные отчеты, а практически во всех системах есть журналы использования объектов, которые можно использовать как счетчики. Спустя годы максимальное количество запусков заказанного топ-менеджерами отчета была 16 раз, среднее - 3 раза.

Другой вариант - обязать секретаршу приносить этот отчет ежемесячно. Тут тоже есть проблема. Первого числа следующего месяца ты успеешь позвонить первым пяти клиентам.
Алло, Юрий Петрович? Это Жора Сидоров, собственник Сидоров и партнеры, есть пара минут? Последние два месяца вы у нас ничего не покупаете - вот звоню, может случилось чего? Если есть - я готов решить их тут же, для нашего дальнейшего сотрудничества. Менеджер Костя подвел? Извините, пожалуйста - вы никогда больше не услышите Костю. Давайте следующие 2 месяца я лично буду вашим персональным менеджером, а после - я дам вам на сопровождение нашего лучшего сотрудника и 5% скидки. итд, итд, итд. На пятом клиенте - тебя отвлекут. Отчет потеряется среди кипы текущих бумаг.
Через месяц первого числа ты успеешь обзвонить только двух клиентов. Потом тебя отвлекут.
А на третий месяц твоя секретарша просто не принесет тебе этот отчет.

А что делать?

Но есть другой вариант - позволь мне назвать его ERPшным.

Ровно на 61й день у тебя пиликает телефон (или почта или СМСка или клиент ERP\CRM) и на экране написано:
Сценарий 23. Регулярный клиент не покупает 2 месяца. Клиента зовут Юрий Петрович. Нажми ТУТ чтобы начать звонок.
Ты жмешь кнопку и начинаешь заученное Алло, Юрий Петрович? Это Жора Сидоров, собственник Сидоров и партнеры, есть пара минут?.
А после конца разговора у тебя появляется меню действий: Отправить свежий прайс, Оформить отгрузку клиенту, "Сменить менеджера", Перезвонить через 2 недели. И на каждый пункт меню - автоматизированная цепочка действий.

А разница-то в чем?

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

Время философии.

И тут мы приходим к трехуровневой проблеме. Эта проблема - не техническая, она управленческая. Или, возможно, психологическая. Или - философская.
Слушай.

Первый уровень проблемы

Ты должен четко понимать что вот-этот-вот месседж в телефоне - это не прихоть программиста и не спам телефона. Это твой, собственника, личный приказ с прошлого - себе-будущему: "Позвони, сволочь ленивая, Юрию Петровичу".
Понимаешь? Ты привык отдавать себе приказы с помощью ежедневника? Позвонить, поздравить, заехать. Вот это - точно такой же приказ. Твой приказ себе самому.
Как только ты это поймешь - дела с внедрением ERP сразу пойдут лучше. Но есть и другая сторона. Если у тебя нет ежедневника или ты привык опаздывать на встречи или твои подчиненные часами ждут тебя после окончания рабочего дня (проще говоря - ты не привык отдавать приказы себе-будущему) - даже не пробуй внедрять ERP. Напрасная трата денег. Это не для тебя.

Второй уровень проблемы

На втором уровне - восприятие твоих подчиненных.
Представь что, по твоему приказу, этот-вот обзвон должен делать коммерческий директор. Это значит что когда его, коммерческого директора, телефон пропиликает - он должен воспринять это как твой приказ.
Все твои подчиненные тоже должны понять что любое управляющее воздействие, пришедшее от ERP - это не прихоть консультанта, программиста или компьютера. Это - прямой приказ собственника. И неисполнение того что пропиликало (или игнорирование пиликанья или непрочтение того что пропиликало) - должно восприниматься как неисполнение твоего приказа, с соответствующими оргвыводами: выговор, депремирование, увольнение.
Это твой приказ. Точка. Как только твои подчиненные это осознают - дела с внедрением ERP\CRM в твоей компании пойдут ну очень хорошо.

Уровень третий. Самый сложный.

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

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

Нужны другие пути. О них мы и поговорим в следующих статьях.

Вступление

Привет. Меня зовут Олег и я занимаюсь внедрениями систем управления предприятиями более четверти века.

Я решил написать цикл статей на основе материалов моей книжки ERP для собственников, которая скоро появится в книжных магазинах.

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

ERP для собственников. Часть 1. Философское.

Проектное vs Операционное

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

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

Следствия

А теперь послушай меня внимательно - ибо здесь один из ключей к пониманию роста и устойчивости твоего бизнеса.

• Операционное от процессного отличается только зрелостью команды.

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

• Изменение зрелости команды для превращения проектного в операционное - твоя, собственника, основная задача.

Не топ-менеджера - ибо он тоже часть команды, зрелостью которой надо управлять. Это твоя, собственника, задача. Или борда, если собственников много.

Технологичное

Продолжу вводить определения.

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

Объясню.
Айвазовский за 60 лет своего творчества написал более 6000 картин. Без сомнений, его деятельность была операционной - он был способен выдавать оговоренные заказчиком результаты в срок, с оговоренными качеством и стоимостью. Но его деятельность не была технологичной - она критично зависела от самого Айвазовского, он был критичным ресурсом. С исчезновением художника производство картин остановилось.
А вот современный Айвазовскому Фаберже сделал производство получивших его имя яиц технологичным: он него лично (как и ни от одного другого мастера в его холдинге) конечный продукт не зависел вообще. Я не зря привел столетней давности примеры Айвазовского и Фаберже - этим я хотел акцентировать внимание на том что технологичной основная цепочка создания ценности может быть вообще без компьютеров и программ.

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

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

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

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

И тут я подвожу тебя к моменту истины.

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

Отсюда три вывода.

Вывод 1

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

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

Вывод 2

Чуть выше я написал что внедрение ERP делает управленцев легкозаменяемыми.
Но для сапиенсов критично важна стабильность. Поэтому первостепенной задачей топов должно стать обеспечение чувства стабильности.

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

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

Вывод 3

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

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

Кнут. О такой независимости мечтает любой рейдер. Если кто-то реализует сценарий враждебного поглощения - бизнес вполне нормально продолжит работать, как будто ничего не случилось. И если рейдеру хватит ума ничего не трогать в настройках - бизнес даже не заметит твоего исчезновения.

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

Читатель, если у тебя нет своего бизнеса - кинь этот линк своему работодателю. Он оценит.

Часть 1: CRM для ERP

Часть 2: Роботизация бизнес-процессов

Часть 3: Волшебные интерфейсы и оживление железа

Часть 4: Автоматические личные кабинеты и чат-боты (в этой публикации)

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

Комплекс систем автоматически работает 24/7 в режиме real-time и полностью реализован за 1,5 года. Хабом является корпоративная ERP-система.

1. Клиенты оформляют заказы в личном кабинете клиента.

2. Заказы из личного кабинета автоматически попадают в ERP-систему.

3. По заказам клиентов в ERP автоматически формируются задания на перевозку.

4. Задания на перевозку в ERP автоматически распределяются между перевозчиками.

5. Заявки на перевозку из ERP автоматически попадают в личный кабинет перевозчика.

6. Перевозчики автоматически из ERP получают уведомления в чат-боте Telegram или по SMS о новых заявках в личном кабинете.

7. Перевозчики берут заявки в работу в личном кабинете и назначают водителей для выполнения доставки.

8. Водители автоматически из ERP получают уведомления в чат-боте Telegram о новых заявках.

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

10. Водители автоматически вызываются из электронной очереди на погрузку в чат-боте Telegram или по SMS, и на LED-табло - подробнее в третьей части.

11. Продукция отгружается на заводе, машины покидают территорию завода и выполняют доставку клиенту.

12. Клиенты автоматически из ERP получают серию уведомлений в личном кабинете, чат-боте Telegram или по SMS об изменении статуса доставки продукции.

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

А теперь подробнее о том, что для этого было сделано...

Личный кабинет перевозчика, распределение заявок и торги, чат-бот для уведомлений в Telegram

Напомню, что завод отгружает ~ 2 млн. тонн продукции в год, из них ~ 50% составляют отгрузки грузовым автотранспортом, что составляет ~ 40 000 рейсов в год.

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

Продукция доставляется клиентам с доставкой или на самовывозе. На завода нет своего грузового автотранспорта, поэтому на доставке задействованы только компании-перевозчики со своими водителями и автопарком.

Контур системы управления зданиями на перевозку включает 4 подсистемы:

1. ERP-система (формирование заявок и распределение между перевозчиками).

2. Личный кабинет перевозчика на сайте (получение заявок по квотам, ежедневные торги, отчеты о выполненных рейсах, объяснительные по опозданиям).

3. Чат-бот для перевозчиков в Telegram (мгновенные уведомления о новых заявках, торгах и опозданиях водителей).

4. Чат-бот для водителей в Telegram (мгновенные уведомления о новых заявках, опозданиях на погрузку и регистрация прибытия на завод), подробнее в третьей части.

Автоматическое распределение заявок между перевозчиками в ERP

В основе алгоритма автоматического распределения заявок между перевозчиками 3 базовых критерия:

• Квота перевозчика (отношение количества транспортных средств перевозчика к общему количеству транспортных средств всех перевозчиков).

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

• Рейтинг перевозчика (выполнение заявок и отказы от выполнения за последние 30 дней).

  Каждой заявке в ERP автоматически присваивается количество баллов от +1 до +4 (срочные заявки и заявки в дальние регионы получают максимальный балл). При отказе перевозчика от заявки баллы автоматически снимаются от -1 до -4. Рейтинг перевозчика это сумма баллов за последние 30 дней пропорционально количеству транспортных средств.

• Общая загрузка перевозчика (процент загрузки транспортных средств перевозчика за последние 30 дней).

  Общий процент загрузки заявками перевозчика за последние 30 дней по отношению у другим перевозчикам за тот же период.

• Есть и другие индивидуальные критерии, но они являются узконаправленными.

  Например: предопределенные грузополучатели перевозчика или бизнес-регионы, в которые перевозчик не осуществляет доставку.

Ежедневно по расписанию 3 раза в день, по заказам клиентов, роботом в ERP автоматически формируются задания на перевозку: 2 раза в день (утром и вечером) задания автоматически распределяются между перевозчиками, 1 раз днем задания попадают на торги.

Личный кабинет перевозчика и торги на сайте

Личный кабинет представляет собой пользовательский интерфейс и не хранит в себе данные. Обмен с ERP-системой выполняется через веб-сервис, API реализовано на стороне ERP.

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

Название профиля пользователя личного кабинета всегда видно при просмотре сеансов в вебвизоре

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

Сайт личного кабинета перевозчика полностью адаптивен для работы на смартфонах и планшетах (сейчас это 50% пользователей).

Личный кабинет перевозчика - мои заявкиЛичный кабинет перевозчика - заявки на торгахЛичный кабинет перевозчика - общие заявкиЛичный кабинет перевозчика - отчеты о рейсах

Общая логика работы перевозчиков с заявками в личном кабинете:

1. Мои заявки

   Это заявки перевозчика по квоте, которые он получил после автоматического распределения в ERP. Чтобы взять в работу или отказаться у перевозчика есть 30 минут, после чего они автоматически становятся общими. Если перевозчик не взял в работу хоть одну заявку или отказался хотя бы от одной заявки, ему до конца дня автоматически устанавливается запрет на взятие других заявок. Это мотивирует перевозчика брать все распределенные ему заявки, а не только "хорошие".

2. Общие заявки

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

3. Заявки на торгах

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

   Все ставки перевозчиков по заявкам автоматически поступают в ERP. Через 30 минут после начала торгов робот в ERP определяет наилучшие ставки и распределяет заявки с торгов на перевозчиков по тем ставкам, которые они сделали в личном кабинете. Это дает существенную экономию по тарифам на доставку - до 20%.

Торги по заявкам среди перевозчиков помогают нам оптимизировать тарифы на доставку. Мы видим предложения перевозчиков и количество ставок по конкретным регионам и зонам доставки, после чего точечно снижаем стандартные тарифы на доставку.

Тот случай, когда перевозчик торгуется за заявку сам с собой

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

В данном случае перевозчик мог снизить тариф всего на 1 рубль и гарантированно получить заявку с торгов, так как кроме него больше никто ставок не делал. Но делая "слепую" ставку перевозчик снижает тариф на 138 рублей (11,15%).

Чат-боты в Telegram для перевозчиков и водителей

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

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

Почему я не сделал мобильное приложение для перевозчиков?

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

Полнофункциональное мобильное приложение, интегрированное в нашей ERP-системой, предложила реализовать только одна компания. Стоимость 10 млн. руб. "под ключ" превышала весь мой годовой ИТ-бюджет на разработку в 2,5 раза.

Другие предложения составляли от 1 до 5 млн. руб. и мы самостоятельно должны были найти интегратора, который за отдельную стоимость "подружит" мобильное приложение с ERP-системой.

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

Разработка личного кабинета перевозчика на сайте, интегрированного с ERP-системой и двух чат-ботов в Telegram в сумме составила всего около 500 тыс. руб.

Кроме того, г-н Дуров Павел Валерьевич разработал прекрасное и стабильное приложение Telegram, в котором есть удобный пользовательский интерфейс, бесплатное и функциональное API для чат-ботов.

Быстрая разработка чат-ботов, которую мы используем

Год назад мы приобрели готовый модуль Платформа интеграции 1С с чат-ботами и встроили его в ERP-систему. Модуль имеет открытый программный код и закрытую часть, а также пользовательский интерфейс для разработки простых сценариев чат-ботов "без программирования", остальные нюансы разрабатываются программистом.

Логика чат-бота разрабатывается на стороне ERP, а встроенный модуль позволяет быстро настроить интеграцию с зарегистрированным ботом Telegram через API-ключ (токен). Для обмена ERP-системы с Telegram используется развернутый на нашей стороне веб-сервис.

Настройки подключения чат-бота на стороне ERP

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

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

1. Новый водитель нажал в чат-боте команду СТАРТ и получил мгновенный ответ.

2. Водитель написал в чат-боте номер своего телефона и получил мгновенное приветствие.

3. Водитель нажал в чат-боте команду Я - ПРИБЛ НА ПОГРУЗКУ и получил мгновенный ответ.

Автоматическое служебное уведомление в чат-бот, когда что-то идет не по сценарию

Как обеспечить работу сервисов 24/7, когда тех.поддержка работает 8/5

Сотрудники линии тех.поддержки работают в режиме 8/5. При работе систем и сервисов в режиме 24/7 мы обнаружили, что веб-сервисы могут молча "отвалиться", а на стороне сервера этого не видно. Чтобы оперативно узнавать об этом, мы разместили на нашем основном сайте небольшой скрипт, который каждые 5 минут опрашивает состояние веб-сервисов.

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

Личный кабинет клиента, чат-боты в Telegram для уведомлений и согласований

В нашей компании всего 6 менеджеров по продажам. 3 менеджера обеспечивают 80% продаж, что составляет ~ 1,6 млн. тонн продукции в год.

КАК БЛО (ручной процесс):

Клиент >отправка заявки по email> Менеджер по продажам >создание заказа по заявке> ERP-система >согласование доставки по заказу> Менеджер по логистике >отправка заявки на доставку по email> Перевозчик >передача информации по телефону> Водитель

Большое количество участников процесса внутри компании. Большое количество коммуникаций между всеми участниками процесса (по телефону, по email, в мессенджерах, лично).

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

КАК СТАЛО (автоматический процесс):

Личный кабинет клиента >заказ клиента> ERP-система >заявка на доставку> Личный кабинет перевозчика >заявка на рейс> Личный кабинет водителя

Участие сотрудников компании сведено к минимуму (только при нештатных ситуациях). Коммуникации между всеми участниками процесса выполняет ERP-система (задачи, уведомления, обратная связь).

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

Дальше подробнее о том, как реализован личный кабинет клиента...

Личный кабинет клиента на сайте, интегрированный онлайн с ERP

Личный кабинет разработан на платформе "1С-Битрикс". Интеграция с 1С реализована через встроенный в ERP стандартный модуль, который прилично доработан. Автоматический обмен реализован через веб-сервис в режиме real-time. Сайт полностью адаптивен для работы на смартфонах, сейчас это 20% пользователей.

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

Интерфейс должен быть одновременно компактным, удобным и функциональным. Чтобы любую информацию пользователь мог получить за 3 клика.

Что для этого сделано:

• Подробный вид (1 клик) карточек договоров и заказов в списках, без открытия формы.

• Замена выпадающих списков (2 клика) на радио-кнопки (1 клик).

• Замена выпадающих списков (2 клика) на чек-боксы (1 клик), когда доступен выбор нескольких значений.

• Автоматический выбор единственного значения радио-кнопки в формах (0 кликов).

• Функционал повтора заказов (1 клик) для создания аналогичного по существующему.

• Пошаговое заполнение заказов для исключения лишних и недоступных действий (кликов).

• Многократное самостоятельное тестирование всех экранных форм на удобство.

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

У каждого статуса заказа свой цвет, текущий статус с датой и временем, общий прогресс выполненияЦветные статусы и общий прогресс выполнения заказов в списках

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

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

Форма создания заказа клиента - пошаговое заполнениеСтраница профиля личного кабинета клиентаНастройки профиля личного кабинета клиентаНастройка уведомлений контактных лиц клиентов

Краткий и полный вид карточек заказов в списке (на смартфоне)Форма запроса счета на оплату (на смартфоне)Форма настройки уведомлений контактных лиц (на смартфоне)

Быстрое получение счета на оплату по email

В личном кабинете клиента реализовано моментальное получение счетов на оплату по email (без участия наших менеджеров по продажам). Ключевая особенность, что счет может быть отправлен на несколько email одновременно.

Клиент запрашивает счет в личном кабинете и получает в почте через 3-5 секунд (именно столько времени требуется для автоматического формирования счета в ERP и его отправки роботом из ERP на email контактного лица).

Счет на оплату автоматически сгенерирован в ERP и сразу отправляются на email контактного лица в формате PDF (на фирменном бланке и с факсимиле).

Чат-боты в Telegram для уведомлений и внутренних согласований

Для уведомлений клиентов о статусе мы используем Email-робота и SMS-робота (подробнее в первой части), чат-бот в Telegram.

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

Чат-боты в Telegram для менеджеров и руководителей продаж

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

Бэк-офис регистрирует новые интересы в CRM-системе (подробнее в первой части), а робот в ERP мгновенно уведомляет менеджеров в чат-боте Telegram.

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

Менеджер по продажам или менеджер бэк-офиса может запросить согласование технического кредита в ERP по различным параметрам:

• С лимитом по сумме

• С лимитом по тоннажу

• С лимитом по количеству машин

• С лимитом по количеству вагонов

• На увеличение ранее согласованного тех.кредита (по сумме, тоннажу, машинам или вагонам)

Пример согласования тех.кредита на отгрузку 1 машиныПример согласования тех.кредита на отгрузку вагонами 140 тоннПример согласования увеличения тех.кредита на сумму 150 тыс. руб.

Руководители двух коммерческих дирекций получают мгновенные уведомления в чат-боте Telegram на согласование тех.кредитов.

Руководитель может инициировать согласование тех.кредита для клиента командой НАЧАТЬ СОГЛАСОВАНИЕ, ознакомившись с информацией - СОГЛАСОВАТЬ или НЕ СОГЛАСОВАТЬ.

Результат согласования мгновенно получает уведомление в чат-боте Telegram ответственный за работу с клиентом менеджер по продажам. Заказы клиентов в ERP автоматически проводятся в рамках согласованных лимитов тех.кредитов, начиная с первого не проведенного по времени создания заказа.

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

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

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

Новая система отгрузки паллет со склада, установленная в кабинет автопогрузчика

Спасибо, что дочитали до конца!

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

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

В типовом функционале ERP существует ряд ограничений:

• Отсутствуют инструменты по инвентаризации ТМЦ в эксплуатации, что для крупных компаний является обязательной процедурой.

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

• Нет единого отчета, который бы аккумулировал в себе все сводные данные по учету спецодежды.

Количественные и суммовые данные разбросаны по нескольким отчетам. Например, чтобы получить информацию о количестве и стоимости ТМЦ в эксплуатации, нужно сформировать ОСВ (оборотно-сальдовую ведомость) по счету и типовой отчет "ТМЦ в эксплуатации", а затем сопоставить данные отчета в единый. При больших объемах данных такой процесс, естественно, усложняет работу пользователям и влияет на рост количества ошибок.

Кроме того, в типовом отчете "ТМЦ в эксплуатации" не отражаются те ТМЦ, по которым срок службы закончился, но сам ТМЦ еще не списан, что в свою очередь влияет на полноту отражения данных по учету.

• Не отражается движение спецодежды по счетам МЦ и 10.11 в рамках одного месяца, если она была передана в эксплуатацию в этом же месяце.

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

Ограничение типового функционала 1С:ERP заключается в данном случае в том, что по счетам МЦ и 10.11 не будет отображаться движение спецодежды в том же месяце, в котором произошла передача и было сделано списание или перемещение. Пользователи не смогут получить полные сведения по эксплуатации одежды в апреле, в котором она и была передана, данные будут отображены только в мае. Такой формат противоречит полноте отображения данных.

• Расчет остаточной стоимости ТМЦ, стоимость которых была погашена при передаче в эксплуатацию.

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

Сейчас в типовой системе 1С:ERP вся спецодежда и спецоснастка (согласно ФСБУ 5), которая передается в эксплуатацию, списывается на расходы сразу, независимо от срока службы. Проблема заключается в том, что при полном списании, когда не учитывается реальный срок службы спецодежды (в учете 2021 в системе не заложены такие документы), нельзя автоматически рассчитать остаточную стоимость, которая важна для формирования возврата средств за спецодежду и финансового результата при реализации.

Может ли автоматизация процессов в 1С решить насущные проблемы учета?

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

Рассматривая данные цели в разрезе учета спецодежды в 1С:ERP, для их достижения необходима автоматизация учета ТМЦ. Для решения вопроса оперативности, полноты и достоверности данных о ТМЦ в эксплуатации был разработан отчет "ТМЦ в эксплуатации" на базе типового отчета 1С:ERP.

Данный отчет позволяет:

• увидеть суммовые и количественные показатели в одном отчете, в разрезе всей необходимой аналитики;

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

• увидеть суммовые показатели по перемещениям и списаниям ТМЦ в том периоде, в котором они отражены по документам, независимо от даты передачи их в эксплуатацию;

• работать с полной детализацией до первичного документа, что позволяет открывать документы сразу из отчёта и вносить в него при необходимости корректировки.

Важный момент: отчет подключается к 1С как внешний инструмент и не рушит текущие процессы системы, в которой работает компания.

Разбираемся с инвентаризацией

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

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

Документ "Инвентаризационная ведомость для ТМЦ в эксплуатации" заполняется автоматически по данным забалансового счета МЦ по сумме и количеству с учетом данных оперативного контура, что позволяет получать актуальные данные после проведения документов перемещения и списания, независимо от формирования проводок в БУ. При этом в документе есть возможность формирования печатных форм ИНВ-3 и ИНВЕ-19.

Автоматическое заполнение реквизитов в документах по учету ТМЦ в эксплуатации

В рамках разработки отчета были доработаны механизмы, позволяющие автоматизировать:

• заполнение стоимости ТМЦ при возврате из эксплуатации, если на момент возврата не вышел срок службы или в принципе есть остаточная стоимость на счете 10.11;

• заполнение реквизитов Физическое лицо получатель при перемещении.

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

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

Если у вас появятся вопросы - оставляйте заявку, мы подробно проконсультируем по функционалу!

В школе все мы решали задачки вида едет из пункта А в пункт Б. Речь преимущественно шла о скорости и времени как быстро доберётся транспортное средство? Реальность, однако, подбрасывает задачки значительно интереснее: Существует масштабная ритейл-сеть по продаже товаров, которой необходимо, чтобы огромное количество номенклатурных позиций доезжало в каждый из 17000 магазинов, расположенных на половине площади самой большой страны в мире, вовремя и в нужном количестве. Для решения такой задачи в X5 Group существует ряд реализованных решений, и одним из самых важных является процесс автозаказа товаров.

Техническую поддержку этого направления в X5 Group обеспечивает команда 2-SAP Логистики.

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

Автозаказ это комплекс процессов управления запасами и заказами

Поддержание объемов товарных запасов на установленном уровне, который обеспечивает постоянное наличие товара при оптимальных запасах в системе. Это достигается путем автоматического выполнения процессов:

Планирование заказа.

Формирование заказа.

Отправка заказа.

Экономическое обоснование поддерживаемого уровня.

Контроль за состоянием запасов.

Управление ассортиментом.

Для этого используются разные механизмы прогнозирования в зависимости от формата магазина и гибких настроек в системе.

Прогноз продаж, построенный SAP это прогноз спроса на период 42 дня, который строится на исторических данных по продажам. Период анализа продаж и модель прогноза определяется из настройки Профиля прогноза.

В периоде анализа продажи могут быть Плановые регулярные продажи и Внеплановые промо продажи.

Прогноз запускается ночью (по календарю) в фоновом режиме массово для всех комбинаций товар-магазин, в рамках ассортимента и является частью Автозаказа.

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

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

Около 04:30 эти данные по потребности из JDA поступают в SAP, где обрабатываются фоновым заданием с интервалом запуска каждые 15 минут, в результате чего создаются Автозаказы.

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

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

Через автозаказ пополняется до 80% основного ассортимента магазинов, а ручное пополнение выполняется для товаров in-out.

Схема реализации товара:

Классическое пополнение происходит примерно в таком виде: представим, что есть некий товар, допустим, это пакет молока, который поставляется напрямую от внешнего поставщика в магазин торговой сети Пятёрочка.

Так выглядит децентрализованная цепочка:

- в 00:00 стартует задание по АЗ, в период его работы по нашему товару рассчиталась потребность, сформировался автозаказ, и он бы отправлен из SAP в программу магазина GK(Пятёрочка), там у сотрудников магазина есть время отредактировать рассчитанное кол-во (в большую или меньшую сторону) до наступления времени автосогласования (например, до 11 утра, время зависит от тайминга поставщика, т.е. до какого момента он должен получить заказ, чтобы собрать и вовремя привезти заказ в магазин);

- после внесения корректировок эти изменения отправляются в SAP, и дальше происходит процесс автосогласования заказ согласовывается и автоматически отправляется поставщику по почте или его провайдеру (в зависимости от того, по какой схеме поставщик работает). Например, если поставщик работает по EDI (через электронный документооборот), то после доставки заказа в его систему, нам провайдер передает информацию о размещении заказа в своем ПО и в системе ER2 заказ переходит в статус Размещен;

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

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

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

• Продажи за период в прошлом

• Прогноз на период в будущее (на основании продаж строится прогноз SAP)

• Остатки на объекте получателе (остаток в SAP на момент расчёта)

• Открытые заказы (заказы на поставку и возвраты)

Продажи приходят из магазинов каждый вечер до расчёта фонового задания Автозаказа.

Факт получения продаж запускает расчет Автозаказа. Если до 03:00 продажи не получены SAP ERP, то происходит безусловный запуск задания Автозаказа.

Автозаказ формируется строго по графику заказа/поставки согласованному с поставщиком, так категории FRESH и ULTRA FRESH, как правило, заказываются и поставляются в магазины ежедневно.

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

Для того, чтобы заказать оптимальное кол-во товара, учитывается прогноз, который строится в SAP в момент расчета Автозаказа.

Если по этому товару уже есть запас или размещенный заказ, который еще не закрыт, то система также учтёт это при определении размера финального заказа.

Автозаказ определяет цепочку и поставщика по каждому товару для каждого магазина, согласно записей книги источников поставок (смежный функционал, автоматизирован, и ведется также в SAP) и формирует заказ.

Запускается задание ежедневно в 00:00. Первыми выполняются расчеты по регионам Сибирь и Урал, далее по регионам Волга, ЮГ, Москва, Центральные регионы и Северо-запад. Последовательность выполнения крайне важна, т.к. наши магазины расположены в разных часовых поясах, и пока в Москве все сладко спят, в Сибири уже в разгаре рабочий день.

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

Для этого мы реализовали различные системы мониторинга, инструменты для анализа, а в случае необходимости и возможность отправки в магазины резервных шаблонов заказа.<o:p>

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

Также предусмотрен инструмент для выгрузки резервных заказов, рассчитанных накануне, в случае сбоев в системе JDA по прогнозированию и пополнению магазинов больших форматов Перекрёсток и Карусель.

... с объектной ориентированностью, сериализацией, reflection, полиморфизмом, визуальным программированием, no-code, блэкджеком и шлюхами - и это на MS SQL 6.5 1995 году!

Знакомые с историей IT при слове "однозвенка" вспомнят dBase и Clipper. Однако, я расскажу об ERP однозвенке. Интерфейсная программа для этой ERP общалась с базой через несколько интерфейсных таблиц и несколько процедур. То есть фактически она является браузером, который за слой не считается. Да, это #ненормальное программирование, которое дало ряд уникальных свойств.

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

Система называлась Ultimа-S, она же Nexus. Судьба ее была незавидна - эта ERP делалась на продажу, а продаж не было. Что, впрочем, было естественно - мы, в том числе автор этих строк, не имели ни малейшего понятия о маркетинге и продажах. Зато я имел удовольствие развлечься за счет работодателя. Итак,

Поехали

Берем установочные скрипты и устанавливаем систему на MS SQL 2019. Правда, базу пришлось загнать в compatibility mode. Запускаем exe. Он, кстати, крошечный (мне пришлось найти ntwdblib.dll):

и в памяти занимает примерно столько же, сколько Notepad:

Запускаем nexus.exe, и открываем иерархию классов:

При использовании возникает очень интересное чувство, которое я не испытывал со времен MS DOS. Многие операции отрабатывают мгновенно. Нет, реально мгновенно. В современных программах, даже WinForms (я уж не говорю про Web), код настолько тяжел, столько динамически отводит памяти и столько раз вызывает GC, что глаз замечает видимые задержки. Мы к ним привыкли и не замечаем. Но когда программа реально рисует окно после нажатия на клавишу за время одного фрейма экрана, то это удивляет. А когда-то, во времена MS DOS, это было нормально.

Как это работает?

Вся коммуникация с сервером происходит через несколько процедур и три (с небольшим) таблицы. Хочется раскрыть папку - вызываем процедуру, передавая id папки, а в результирующую таблицу сваливается список документов, которые там находятся. Причем клиента не интересует, как этот список получился.

Делаем right click и хотим получить список свойств?

Тоже через таблицу. Пользователь видит user friendly имена свойств, а еще у них есть системные id, среди которых - как правило 'view' (read only просмотр по умолчанию) и 'edit' (основное редактирование).

Наконец, мы выбрали свойство и хотим посмотреть документ. Результат выдается через таблицу Detailed где есть id полей, значения (есть колонки для разных типов) и колонку форматирования. Это поле в первой букве содержит тип значения int, float, money, string, document (который на самом деле тоже int), а дальше название для человека и некие теги указывающие поведение, например: fширина^min=0^max=10.0

Вас конечно заинтересовало, если таблицы для коммуникации общие, то как могут одновременно работать много клиентов? Все очень просто - у всех этих таблиц есть поле spid (=@@spid). А все клиенты открывают ровно одну коннекцию и используют только ее (да, такой дизайн был нормой). Никаких connection pools. Представляете как легко сделать пессимистичные блокировки - по spid вы точно знаете что клиент не отсох и даже с какого hostnamе он работает!

Обычно клиент располагает поля сверху вниз, но для важных документов могут быть задизайнены красивые формы. И да, теперь языком дизайна был бы наверняка HTML, а языком сценариев (min^ max^ и полее сложные пересчетом totals) был бы JS.

Объектная ориентированность

Все документы в системе произведены от общего класса Doc. При создании производных классов создаются документы типа Класс, осуществляя своеобразный Reflection. Часть иерархии классов вы могли видеть на первом скриншоте. Классы могут быть и абстрактными.

При выполнении операции (раскрытия папки, получения свойств и отображения) вызываются процедуры с именами вида Class_operation_ID_, причем вначале идет волна 'pre' свойств, начиная от Doc к листьевому классу, а потом 'post', в обратном направлении, от листа к корню. Как правило, все свойства pre, а post полезен для удаления данных (удаления лучше делать обратном порядке, от detail таблиц к master).

Для pre свойство очередного класса 'видит' что натворили классы под ним, поэтому может не просто добавить поле или свойство, но и 'надругаться' над тем, что сделано до него - переименовать свойство или вообще убрать его, сделать поля read-only, дать им умолчания или вообще скрыть поля с помощью специального флага (но не удалять - иначе будут проблемы при записи)

Ниже вы видите пример процедур на SQL, к которому был прикручен самописный макроязык. Обратите внимание как производный класс изменяет friendly name свойства пользователя, а также иногда добавляет новое свойство.

Работа через Detailed давала еще одну интересную возможность: сериализация. Ведь можно просто вызывать свойство view (например), получить ответ, и запомнить его. Получалась мертвая копия, ксерокс, но выглядела она как настоящий документ - только была read-only.

Аналогично, Аудит (история изменений) работала на уровне корневого класса Doc, сравнивая Detailed до и после редактирования. Все производные классы были освобождены от необходимости следить за аудитом редактирования!

No-code

Система позволяла мастерить новые документы прямо через интерфейс. Сейчас покажу пример. Создадим класс, производный от пользователя:

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

Теперь через right click на образовавшемся классе создадим расширение, то есть новое поле - число пальцев от 5 до 10.

Теперь мы создаем сотрудника, указав число пальцев 5, и записываем его.

Посмотрим на результат. Новое поле добавилось внизу:

Сравним обычного пользователя и VIP пользователя. Благодаря полиморфизму (в одной папке могут быть документы любого типа) мы можем положить в папку и обычного пользователя и VIP:

С помощью No-code можно было создать сложные документы, с таблицами в духе товар-количество-цена и полем общая сумма, которая пересчитывалась автоматически - и это все без единой строчки кода. Данные ('расширения'), правда, хранились в универсальной таблице, что плохо с точки зрения производительности. Поэтому такие вещи предназначались для маленьких дополнений, а основной код все-таки писался на TSQL

Вершиной no-code был user assistant - метод переопределения поведения любых полей.

Администратор мог для любого документа, для любого поля, для определенной группы пользователей добавить умолчание, сделать поле read-only (что вместе с умолчанием заставляет использовать только определенное значение), или спрятать поле вовсе. Для полей выбора документов можно было изменить Root (папку начиная с которой выбираются документы для ввода) - например, пусть Вася Пупкин при создании платежки сможет указывать только этих трех клиентов (накидаем ссылки на этих клиентов в отдельную папочку)

Фильтрация

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

Через систему событий опрашивались все классы - а по каким полям ты умеешь фильтроваться?

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

Заключение

С тех пор я не видел потенциально более гибких систем. А монстры типа SAP R/3 живут и процветают...

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

Самый популярный способ автоматизировать бизнес-процессы

Обычно бизнес-процессы представляют вот такими схемами в стиле BPMN:

Большинство процессов состоят из одних и тех же действий:

• загрузка документа (или заполнение по готовой форме)

• проход документа по цепочке сотрудников (которые либо вносят в него какую-то информацию, либо согласуют, либо просто уведомляются)

• условия (определяют дальнейший ход процесса)
  и т. д.

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

Редакторы BPMN (и похожих на BPMN) схем реализованы во многих продуктах. Например: Тезис, ELMA, Bitrix. И это неплохой подход, который не хочется даже критиковать, но раз уж будем рассматривать альтернативы, нужно обозначить его недостатки:

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

2. Схема описывает логику работы, но не описывает интерфейсы. Как это будет выглядеть глазами пользователя? Обычно для этого используют заранее подготовленные интерфейсы для разных видов задач (один - для загрузки документов, другой - для согласования, третий - для уведомления пользователей).

3. Схема описывает процесс, но не описывает содержимое документов. Для них нужен еще один редактор - конструктор форм. Причем само содержимое документов может влиять и на ход процесса (например, документ Заявка на оплату содержит поле Сумма, заявки с маленькой суммой согласует менеджер, а большие обязательно проходят через финдиректора).

В итоге, порог вхождения оказывается настолько высоким, что многие процессы проще организовать пересылкой документов по электронной почте. Ну и ведя реестр в экселе для порядку. Это не критика самой BPMN нотации. Часто без нее просто не обойтись. Вопрос вообще не в нотации, а в предлагаемом заказчику продукте. Кажется, для многих задач можно обойтись более простыми инструментами.

Альтернативный подход

Проблематика понятна, что же мы предлагаем?

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

А выглядит так:

Рассмотрим на примере простого процесса согласования:

1. менеджер проекта может подать заявку на расходы (надо ему купить что-то для проекта)

2. заявку должен согласовать начальник отдела

3. затем одобрить финансовый директор

4. затем бухгалтер отправляет оплату в банк

5. и после того, как контрагент подтверждает оплату, менеджер закрывает вопрос

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

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

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

• открыто

• согласовано начальником отдела

• согласовано финдиректором

• оплачено

• закрыто

Причем каждый сотрудник может перевести заявку только в определенные статусы, это указано в настройках правил Статусов.

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

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

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

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

Директору интересна общая картина, какие заявки в каком статусе и в каком отделе - делаем двухуровневую группировку по Начальнику отдела и Статусу:

Бухгалтеру вообще ничего не интересно, он просто хочет видеть какие заявки надо оплатить. Фильтруем только статус Согласовано финдиректором:

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

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

В общем, если бы Ален Карр знал об этом методе, то написал бы о нем книгу, которая, наверняка, стала бы бестселлером)

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

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

Что дальше

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

И да, все эти решения не новы, наверняка многие увидели знакомые приемы из CRMок и таск-трекеров (Jira, Redmine), чем-то это похоже и на Airtable, Notion, Planfix, и даже на Unity 3D (там тоже каждый игровой объект является набором компонентов, которые определяют его поведение). Но в приложениях, автоматизирующих процессы промышленных компаний, примеров не много.

Сейчас у нас в разработке несколько IT-продуктов (стек: Java, MongoDB, React) и мы в поиске разработчиков. Если вы знаете таких спецов, поделитесь с ними ссылкой. Если есть идеи, как это лучше реализовать, поделитесь мыслями. Если же видите слабые места этого подхода, я (тот, кто продвигает идею в нашей компании) открыт к критике и обсуждениям. Для связи - комменты и телега @planer484.

Вводная часть

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

За весь период проекта (он еще идет), мы усвоили много уроков, ведь внедрение системы - это целая история, которую невозможно рассказать одной статьей, для этого мы решили выпустить серию статей с периодичностью.

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

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

Что такое Полипропилен? Это основной материал для производства современных видов пластика, он используется в пищевой, машиностроительной, медицинской промышленности, является основой для создания упаковочных материалов и труб, оргтехники и мебели.

Основная цель безлюдное производство, цифровой завод. Первый шаг навстречу цели - внедрение системы SAP S/4HANA с максимальным использованием стандарта.

Объем проекта

Внедряемые продукты SAP

• SAP S/4HANA

• SAP Fiori LaunchPad (Цифровое окно)

• SAP HCM

• SAP BPC

• SAP MII

• SAP PO

Автоматизируемые процессы

• Бюджетирование

• Финансы

• Снабжение и Сбыт

• Производство и ремонты

• Управление персоналом

• Единое цифровое окно

Особенности работы в удаленном режиме

Обучение ключевых пользователей

Передача знаний на расстоянии

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

По ходу проведения тренингов мы определили несколько хороших практик по организации и проведению дистанционного обучения по работе в SAP. Их можно объединить в следующие блоки:

Подготовка тренинга:

• Для дистанционного обучения мы использовали инструмент MS Teams, который является аналогом нашумевшего ZOOM, но более корпоративный. Данный инструмент позволяет сделать видеозапись звонка, которую пользователи также в дальнейшем смогут использовать для повторения пройденного материала.

• Для ответов на контрольные вопросы и сбор обратной связи мы использовали MS FORMS. Очень удобный инструмент, который позволяет пользователям сразу увидеть свою оценку и экономит время тренеров на проверку. С его помощью можно создать тест, и даже выгрузить его результаты в формате Excel, что позволяет с легкостью отслеживать статистику и делать сводные таблицы. Плюс - ограничений по количеству форм (тестов) нет.

• Сформировали группы на обучение в размере не более 10 человек. И соответственно рассчитали время тренингов. В случае увеличения численности группы время тренинга увеличивалось.

• На каждый тренинг был назначен 1 основной тренер и 1 помощник, который в процессе тренинга направлял в чат тренинга необходимые ссылки и названия транзакций.

• Лучше заранее проверить Интернет-связь, как на стороне тренеров, так и на стороне пользователей, чтобы не было рассинхронизации голоса и трансляции экрана.

Организация рабочего пространства пользователей:

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

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

• Нужно заранее установить все необходимые для обучения программы на компьютеры пользователей, выполнить в них первоначальных вход и запомнить свои учетные данные. Мы столкнулись с тем, что у некоторых пользователей ПО установлено просто не было, в связи с этим было затрачено много времени, на его установку и на решение этой проблемы. Это поможет значительно сэкономить время во время тренинга на осуществление первого входа.

Организация учебного процесса:

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

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

• Пользователям удобнее, если тренер не просто показывает на своем экране, а присылает в чат встречи название изучаемой транзакций и данные для выполнения упражнения (например, название материалов или номер договора для каждого пользователя).

• Так как у нас на обучении была взрослая аудитория, то эффективно удерживать внимание получалось примерно в течение 1 1,5 часов. Далее требовалось сделать перерыв на 10-15 минут. Это необходимо учитывать при планировании времени тренинга. Максимальная продолжительность тренинга в течение дня для одной группы обучающихся без потери качества обучения 4 часа.

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

• Очень полезно в начале тренинга обозначить цели тренинга, а в конце - сделать резюме того, что прошли. Если тренинг разбит на два дня, то второй день начинаем с резюме первого дня. Чтобы на фоне операционной работы к пользователям вернулись приятные воспоминания вчерашнего тренинга и появилось приятное осознание, сколько уже было пройдено.

Лайфхаки, или наши полученные уроки:

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

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

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

Тестирование функционала системы

Как протестировать функционал системы в удаленном режиме на предприятии, которое еще в процессе строительства?

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

План проведения тестов функциональности системы строился исходя из календарного плана запуска функциональных направлений в продуктивную эксплуатацию, готовности настроек и разработок. Как и при планировании мероприятий всего проекта, так и для мероприятий тестирования использовался подход waterfall.

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

• Функциональное это локальное тестирование возможностей системы. При таком тестировании осуществляется проверка системы в рамках объектов функционального направления;

• Интеграционное позволяет проверить насколько корректно отрабатывает функционал при взаимодействии со смежными функциональными направлениями;

• Приемочное тестирование функционала Заказчиком, которое позволяется удостовериться что система отвечает заявленным требованиям непосредственно заявителю данного функционала.

1. Организация процесса тестирования:

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

   В качестве основного предполагался удаленный формат проведения тестирования с использованием видео трансляции процесса. В качестве инструмента организации видео конференции был выбран MS Teams.

   Для проведения тестов использовались отдельные ландшафты системы с подготовленными данными, полученными в ходе проведения циклов миграции.

2. Интеграционное:

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

3. Приемочное:

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

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

Концепция раннего старта:

Реально ли внедрить систему так, чтобы какие-то отдельные её части запустились раньше, а какие-то позже? Да!

В ходе проекта было принято решение разбить старт проекта на 3 старта Ранний (Корпоративные функции), промежуточный (Планирование и Бюджетирование) и Основной (Производство, Ремонты, Цифровое окно). Концепция раннего старта подразумевает старт отдельных частей раньше, чем старт всей системы в целом. Такая концепция существенно облегчает миграцию, интеграцию, упрощает склейку отчетности HR и Бухгалтерии в начале финансового года, позволяет сфокусироваться на задачах Корпоративных функций до их стабилизации, а потом уже на Производстве и Ремонтах.

На проекте применялся классический подход Waterfall, который подразумевает мобилизацию, анализ и проектирование, реализацию, тестирование, поддержку после запуска.

Для отдельного направления Цифровое окно применялась методология Scrum.

Для управления развитием системы после раннего старта будет применяться Hybrid Agile.

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

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

Итак, по порядку.

Интеграционные платформы: как выбрать?

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

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

Согласно SAP CIO Guide: Process and Data Integration in Hybrid Landscapes, существуют следующие классы интеграционных систем:

Process Integration охватывает интеграцию распределённого между системами/приложениями бизнес-процесса. Наиболее предпочтительные инструменты интеграции на базе ESB (Enterprise Service Bus)

Data Integration охватывает синхронизацию данных между приложениями, базами данных и озером данных вне транзакционного контекста. Наиболее предпочтительные инструменты интеграции на базе ETL (Extract, Transform, Load).

User Integration охватывает все задачи интеграции между сервером приложений и интерфейсами взаимодействия с пользователем.

Thing Integration охватывает все сценарии, когда данные из устройств, оборудования должны быть интегрированы с бизнес-приложениями.

Cross Use Cases остальные сценарии, применяемые для сквозного взаимодействия.

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

Опыт российской практики показывает, что компании в основном делают выбор в пользу таких интеграционных систем, как SAP PO (ранее SAP PI). Однако существуют и другие системы, которые также предназначены для интеграции между системами различных уровней. В нашем случае мы использовали интеграционные системы SAP PO и SAP MII.

Ключевые аспекты использования SAP PO и SAP MII

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

1. SAP PO следует использовать для интеграции процессов в качестве основной Корпоративной сервисной шины (ESB) предприятия (Например, ERP с Банк-клиентом), а также когда требуется:

Использовать репозиторий корпоративных сервисов в качестве центрального репозитория SOA

Использовать поддержку дополнительных стандартов WS (web service), таких как UDDI, WS-BPEL, и задач, WS-RM в корпоративной среде.

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

Использование новых функций, таких как аутентификация конечных пользователей, валидация XML и возможности BAM

Взаимодействие с системами, находящимися за рамками DMZ корпоративной сети.

2. SAP MII следует использовать в основном, когда стоит задача обрабатывать данные уровня заводов (MES, LIMS), которые представлены в разнородных хранилищах, которые требуется организовать и проанализировать, а также, когда нужно:

Получать согласованные отчеты о производственных операциях на разных сайтах.

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

Подключить собственные производственные приложения к данным и рабочим процессам SAP S/4HANA - через стандартные и встроенные адаптеры и инструменты (BAPI/RFC синхронный запрос).

Позволить персоналу предприятия выполнять отчетность (стандартную, мобильную и специальную) наряду с базовыми задачами.

Следует отметить, что система SAP MII по своему прямому назначению, помимо выполнения функции интеграционной шины, также дает возможность выполнять оперативные функции с использованием UI/UX-приложений и реализовать процессы по регистрации данных оперативного учета. Однако использование системы SAP MII только как платформы интеграции не дает никаких преимуществ по сравнению другими системами (например, SAP PO).

3. Наряду с отдельным использованием платформ SAP PO или SAP MII (рассматриваемых в данной статье) также нередки случаи совместного использования одновременно двух этих систем, а именно в тех ситуациях, когда:

SAP MII должен взаимодействовать c SAP S/4HANA (и другими системами корпоративного уровня) через SAP PO в интеграционных сценариях, требующих гарантированную доставку.

SAP PO должен использоваться для централизованного управления потоками данных.

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

В SAP MII должны быть реализованы правила и обработки, специфичные для уровня завода.

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

Преимущества и недостатки SAP PI

Несмотря на то, что верхнеуровнево и SAP PO, и SAP MII поддерживают схожие сценарии интеграции, обе системы разработаны с учетом конкретных сценариев использования.

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

Среди недостатков функционала обеих систем отмечены следующие:

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

Вызовы нашего проекта, и как мы с ними справились

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

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

В связи с этим мы пересмотрели весь рабочий процесс, а именно:

1. Определили временные периоды, в рамках которых сотрудники могли начать и закончить свой рабочий день.

2. Перешли на scrum-методологию:

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

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

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

3. Хорошей практикой стала демонстрация Клиенту прототипа интеграционного решения. Мы показываем не только интеграцию, но и реализацию бизнес-процессов, и таким образом исключаем неприятные неожиданности.

4. Мы сделали оптимизацию с учетом разных часовых поясов:

Приоритизировали и распределяли задачи в соответствии с часовым поясом членов команд

Планировали ключевые встречи с учетом разницы во времени

С пониманием относились к экстренным запросам во внерабочее время.

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

Пересмотренный подход позволил нам скоординировать работу команд и её в срок.

Выводы

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

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

На собственном опыте мы знаем, что выбор всегда не прост, но возможен. И все проектные вызовы можно преодолеть и обратить в свои преимущества.

Надеемся, наша статья поможет вам в поиске наилучшего для вас решения. Да пребудет с Вами Сила!

1. Адаптированная методология Anchor modeling

Архитектура ядра хранилища данных должна соответствовать описанной ниже адаптированной (не оригинальной) методологии Anchor modeling (но не Data Vault).

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

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

В ядре хранилища данных не должны использоваться значения NULL, за исключением тех атрибутов связей, которые не входят в составной ключ (обычно это наименования, обозначения, коды, ссылки, выбранные значения, флаги). Если неизвестны начало и/или окончание срока действия записи, то должны указываться принятые условные даты (например, '0001-01-01', '-infinity', '9999-12-31', 'infinity').

Для облегчения создания полиморфных связей двухсимвольный код в именах должен совпадать с двумя последними символами в соответствующих суррогатных ключах, которыми обозначается тип сущностей или атрибут связей (см. ниже). Поэтому в нем необходимо использовать символы алфавита Crockford's base32.

Таблицы типа узел (knot) исключены из адаптированной методологии Anchor modeling. Однако типовое обозначение узла на схеме в виде квадрата с закругленными углами удобно использовать для обозначения атрибутов связей.

Набросок БД может быть сделан (в том числе, офлайн) с помощью наглядных и удобных веб-инструментов Online Modeler или Online Modeler (test version), но сгенерированный ими SQL-код непригоден для использования. Для генерации SQL-кода (включая SQL-запросы) по методологии Anchor modeling все известные компании используют самостоятельно разработанные ими инструменты на основе языка программирования Python и Microsoft Excel.

2. Суррогатные ключи в адаптированном формате ULID

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

В качестве суррогатного ключа должна использоваться адаптированная (не оригинальная) версия ULID (но не UUID), имеющая любой из двух форматов:

• ttttttttttrrrrrrrrrrrrrrxx (пример: 01F5B023PBG3C48TSBDQQ3V9TR)

• ttttttttttsssrrrrrrrrrrrxx (пример: 01F5B023PB00448TSBDQQ3V5TR)

где

t дата и время генерации с точностью до миллисекунды (Timestamp) (10 символов или 48 бит), UNIX-time в миллисекундах (UTC)

s счетчик от 0 до 32768, сбрасываемый каждую миллисекунду, (Sequence) (3 символа или 15 бит)

r случайное число (Randomness) (14/11 символов или 65/55 бит)

x тип сущностей (Entity type) (2 символа или 10 бит)

Должна использоваться кодировка и алфавит Crockford's base32.

Генератор ULIDов должен удовлетворять следующим требованиям:

1. Соблюдение требуемого формата ULIDов

2. Однократное использование каждого генерируемого ULIDа в качестве суррогатного ключа сущности

3. Использование (достаточно производительного) криптографически стойкого генератора псевдослучайных чисел или генератора истинно случайных чисел

4. Монотонное возрастание ULIDов в интервале менее миллисекунды (за счет инкремента случайного числа для формата без счетчика, или за счет счетчика для формата со счетчиком)

5. Генерация ULIDов в формате (текстовый, бинарный, UUID или целочисленный), наиболее производительном для операций поиска в применяемых СУБД и носителе данных (HDD или SSD)

6. Пиковая (в течение 5 мс) производительность генерации ULIDов должна быть выше максимальной производительности записи в применяемых СУБД и носителе данных (HDD или SSD) (например, за счет буферизации заранее вычисленных частей ULIDа)

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

3. Указание начала и окончания срока действия записи

Для сохранения историчности данных должен применяться второй тип медленно меняющегося измерения SCD2 с добавлением двух унифицированных полей (столбцов): Дата и время начала срока действия записи (имя столбца с суффиксом _FROM) и Дата и время окончания срока действия записи (не включительно) (имя столбца с суффиксом _BEFORE).

Единственным условием связи записей в таблицах, помимо суррогатного ключа, должно быть одновременное действие (valid time) связанных записей, определяемое унифицированными полями начала и окончания срока действия записи, но не датой загрузки в систему или датой создания записи (transaction time). Данные не должны храниться в форме срезов на отчетные или на текущую дату или за календарный период (например, месяц).

4. Указание даты и времени создания записи

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

Примеры имени поля: TR_TIMESTAMP, TR_TDT_TIMESTAMP, TR_AC_DC_TIMESTAMP.

5. Только внешние источники пунктов классификаторов

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

Если при загрузке свежей версии классификатора изменился (исчез, появился) пункт классификатора, то должны автоматически рассчитываться и указываться окончание срока действия прежней запаси, а также начало и окончание действия новой записи.

6. Фасетная классификация

Необходимо по возможности использовать фасетную классификацию вместо иерархической классификации.

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

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

• признак счета активный/пассивный,

• глава,

• раздел,

• счет первого порядка,

• тип контрагента,

• срок.

7. Теги

Если есть большое количество атрибутов с логическими значениями true и false, то эти атрибуты удобнее заменить соответствующими тегами, которые можно хранить в одном поле типа array, типа hstore или типа jsonb.

8. Полиморфные связи

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

Однако использование таблиц связей в таких случаях нежелательно, так как их будет слишком много, и на их поддержание будет затрачиваться слишком много ресурсов IT-подразделения.

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

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

9. Устранение витрин данных

Каждый отчет должен формироваться непосредственно из реплики ядра хранилища данных.

Нежелательно использовать витрины данных, так как они сводят на нет все достоинства методологии Anchor modeling. Особенно большими недостатками обладают универсальные витрины данных, предназначенные для формирования любых видов отчетности.

10. Типовые SQL-запросы и материализованные представления

Разработка SQL-запросов к базе данных, соответствующей методологии Anchor modeling, трудоемка. Поэтому для облегчения работы системных аналитиков и SQL-программистов могут быть созданы типовые SQL-запросы или материализованные представления, соединяющие сущности с их атрибутами на задаваемую дату. Но использование таких SQL-запросов и материализованных представлений может привести к усложнению БД и снижению производительности. Поэтому для рабочей системы вместо них необходимо использовать автоматическую генерацию SQL-запросов (с использованием языка программирования Python и Microsoft Excel).

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

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

11. Вынесение логики из программного кода в таблицы решений

Логику необходимо по возможности выносить из программного кода на языках программирования, SQL и различных ORM в таблицы решений. Например, в таблице решений может быть закодирован выбор дебетуемого синтетического счета в зависимости от типа операции, категории контрагента и срока погашения финансового инструмента. Таблица решений может быть реализована двумя способами:

• таблица сущностей правил, к которой привязаны входные атрибуты и один выходной атрибут,

• таблица связей, соединяющая входные сущности и атрибуты с выходной сущностью либо с выходным атрибутом.

Первый способ очевидно более гибкий и упорядоченный.

Что такое iDempiere?

iDempiere ERP/CRM - это бесплатное ПО с открытым исходным кодом. Имеет функционал Tier II ERP, CRM, SCM, POS, Promotion, Campaign management и, в принципе, много чего ещё.

Важно понимать, это не просто бизнес-приложение - это Java платформа/конструктор для low-code разработки разных, ориентированных на работу с базой данных, бизнес-приложений c web интерфейсом. Во времена, когда многие пытаются построить бизнес-приложение с нуля, хорошо помнить о том, что существуют подобные фреймворки, основанные на принципах ООП, с миллионами строк проверенного кода, "активным словарём данных", который позволяет управлять сущностями, правилами проверки, окнами, таблицами, форматами и другими настройками приложения, не прибегая к кодированию вообще или же применяя небольшие, в несколько строк, инъекции кода.

Входит в широко известное за рубежом семейство "...piere" - Compiere, Adempiere, Open Bravo, Metafresh. Отличается от одних из них полным отсутствием pay wall, от других - модульной (плагинной) архитектурой (менять функциональность системы можно на лету, обновляя тот или иной плагин OSGi).

Каждый год на Хэллоуин сообщество проекта выпускает обновлённую версию. Осенью 2020 года вышла версия 8.2.

"Кривая обучения команды по iDempiere ERP/CRM была пройдена ранее, на предыдущих проектах. За нашими плечами есть проект на промышленном предприятии: 500 активных пользователей в день, база около 500 Гб, 100-400 млн. запросов к базе в сутки."

Если верить официальным сайтам этих близкородственных систем, а также зарубежных фирм-внедренцев, данное семейство ПО используется в Ив Роше (Франция), Декатлоне (Индия), Цирке дю Солей и в тысячах безвестных фирм, от Канады до Индонезии, в разных секторах, от производства молока до банковского сектора.

iDempiere работает с PostgresSQL >=9.6 или Oracle 11G/12C. Даёт кластеризацию серверов приложений и балансировку нагрузки с помощью HAProxy и Hazelcast. Имеет write to Master & report from hot replicas, два движка автоматизации бизнес-процессов ("строгий" бизнес-процесс и бизнес-процесс для кейс-менеджмента) и мн. др. фичи, делающие её вполне пригодной для большой индустрии.

Данный "панегирик" не что иное, как благодарность данной системе в режиме word of mouth за её возможности, которыми уже не раз приходилось пользоваться, в полном соответствии с философией open source и sharing.

"300 магазинов разбросаны на площади 450 тысяч км. кв., что примерно равно площади Испании. Объезжать их все, даже на моноколесе, - дороговато."

В чем состояла задача в данном проекте?

В 300 магазинах, которые работают по франшизе бренда и в которых сложился разношёрстный ИТ-ландшафт различных POS-систем и зачастую нет постоянного айтишника, развернуть программу лояльности, которая максимально соответствует пользовательской истории Заказчика (бренда), работает мгновенно и готова к omnichannel. Часть этой пользовательской истории мы написали и переписали вместе с Заказчиком.

Вот чем в процессе этой дискуссии мы озаботились.

Почему программы лояльности вызывают скепсис у покупателя?

Еcли верить большим дядям типа Forrester, этот скепсис есть во всем развитом мире, а не только у нас. 60-70% всех покупателей являются членами хотя бы одной программы лояльности. Но быть членом это одно, а реально пользоваться - это другое. Как минимум 50% "участников" среднестатистической программы лояльности ею не пользуются. Если коротко и только о главном, то вот почему:

• Проблемы бренда:

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

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

• Проблемы самой программы лояльности:

  • Правила участия и получения бенефитов замороченные

  • А награда находит покупателя не сразу, а только потом - отсутствует instant gratification.

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

"Тут и объяснять ничего не надо - каждой программе лояльности нужен BI и всё тут. Для нашего проекта мы опять решили использовать open source - Metabase. Заказчику понравилось"

Какие принципы программы лояльности мы с заказчиком в итоге сформулировали?

Возможно, вам это всё покажется прописными истинами, но всё же.

Вырваться из замкнутого круга скидок и перейти к баллам

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

В центре программы лояльности - покупатель

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

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

Баллы покупателя, заработанные им при покупке, должны быть доступны для списания не на следующий день, а сразу, при следующей покупке, не важно, в этом же твоём магазине или уже в онлайне (если у тебя есть онлайн). То есть все твои сервисы, и оффлайновые и онлайновые, должны работать с одними данными покупателя и при этом работать почти мгновенно.

Регистрация в программе лояльности за секунды. И никаких ФИО, пожалуйста!

Понятно, что бумажные анкеты, которые "завтра обработают в офисе" это безнадёжный олдскул. Зарегистрироваться твоему покупателю в твоей программе лояльности должно быть не сложнее, чем послать 1 СМС. Ещё лучше, если это в два клика сделает продавец прямо в магазине. И, боже мой, конечно, не надо спрашивать Имя-Фамилию-Отчество! Спроси "Как к Вам можно обращаться?". Если хочет покупатель быть Василисой Прекрасной, Darth Vader или Zaya, пусть будет, мы не на пограничном контроле. Твоя задача - максимально снизить боль покупателя при регистрации, и дать возможность покупателю быть тем, кем он хочет, это лояльно по отношению к нему. Удивительно, но сколько же людей из сферы маркетинга порываются мыслить терминами "ФИО"!

Максимальная прозрачность для покупателя условий программы лояльности и его статуса в ней

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

Заранее планируй multichannel и работу множества разных акций одновременно

Даже если онлайн-магазина у тебя ещё нет, всё равно архитектуру и логику своего offer engine закладывай под

• многоканальность (физический магазин, онлайн-магазин, приложение, бот в Телеграме и т.д.)

• каждая торговая точка - потенциально отдельный канал (позитивно аукнется, например, при открытиях новых магазинов или при региональных промо)

• сосуществование множества акций одновременно (в т.ч. "противоречащих" друг другу)

Акции должны быть настраиваемы для одного отдельного канала (отдельная торговая точка, интернет магазин, приложение, телеграм-бот и т.д.), либо для набора из нескольких каналов, либо для всех каналов. Что там маркетологу будет угодно.

Скорость и надёжность, само собой

Прикинь сразу максимально возможное количество транзакций в твоей программе лояльности, в пиковый день, в пиковый час. Новые торговые точки, сезонность, праздники, все дела. В нашем случае мы с заказчиком заложились на 900'000 транзакций в день.

Подарочные карты

Надо, Федя, надо. Это профессионально, поэтому, рано или поздно неизбежно. По крайней мере, заложи в архитектуру заранее.

FIFO для баллов программы лояльности

Баллы в программе лояльности начисляются, баллы списываются. Зачастую, неиспользованные баллы той или иной программы лояльности сгорают после определённого периода невостребованности покупателем. Даже если этот цинизм не про тебя, возможность иметь "партионный учёт" баллов и их связь с конкретными покупками даст тебе гибкость в политике списаний и точность в анализе.

Анализируй это!

Тут и объяснять ничего не надо - каждой программе лояльности нужен BI и всё тут. Для нашего проекта мы опять решили использовать open source - Metabase. Заказчик остался доволен.

Итак, проблемы проекта

1. 300 магазинов разбросаны на площади 450 тысяч км. кв., что примерно равно площади Испании. Объезжать их все, даже на моноколесе, - дороговато.

2. Да, магазины работают по франшизе, но исторически сложилось, что каждый предприниматель использует POS систему, выбранную по своему усмотрению (уже была; брат/сват уже использует и хвалит и т.д.) 99.9% всех рассматриваемых предпринимателей используют 1С разных версий и конфигураций. Затевать проект по переводу всех на один единственно правильный вариант POS, перестройке работы и переобучению всех сотрудников этой многоликой Испании, да еще в условиях пандемии, заказчик посчитал слишком дорогим по времени, а значит, по деньгам.

3. ИТ-экспертиза в этих магазинах имеет преходящий характер. Или приходящий.

4. НСИ только частично синхронизирована.

5. Период полного развёртывания программы лояльности во всех магазинах был определён как 6-9 месяцев от начала до конца.

"Штатные возможности iDempiere ERP/CRM для предметной области retail & promotion были полностью в нашем распоряжении..."

Сильные стороны, или почему всё получилось

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

2. Предприниматели, работающие по франшизе бренда, смогли мобилизовать свои скромные ИТ ресурсы на относительно локальную ИТ-пертурбацию в виде нормализации НСИ и подключения к разработанному для них API.

3. Кривая обучения команды по iDempiere ERP/CRM была пройдена ранее, на предыдущих проектах. За нашими плечами есть проект на промышленном предприятии: 500 активных пользователей в день, база около 500 Гб, 100-400 млн. запросов к базе в сутки.

4. Штатные возможности iDempiere ERP/CRM для предметной области retail & promotion были полностью в нашем распоряжении:

   1. Вкладка Контрагент и её разные подчиненные вкладки (Контакты, Адреса, Сферы интересов, и ещё пара десятков других) и их готовая логика;

   2. Вкладка Промоакция и её подчиненные вкладки (Условия срабатывания, Распределение количества, Вознаграждение для покупателя, Строка промоакции и др.) и их готовая логика;

   3. Вкладка Группы Промоакций;

   4. Вкладка Рекламные кампании;

5. Плюс штатные фичи iDempiere из смежных областей, которые тоже пригодились:

   1. Сильный буржуйско-бухгалтерский функционал по GL (General ledger - Главная книга) и учёту дебиторки/кредиторки;

   2. Работа со множеством валют в учёте (баллы - это просто ещё одна валюта, пока что с курсом 1:1 к рублю);

   3. Встроенный Report Cubeи таблица Fact_Acct_Summary, хранящая балансы финансовых транзакций (отличная от таблиц, содержащих движения);

   4. Кластеризация серверов приложений и балансировка нагрузки с помощью HAProxy;

   5. Поддержка REST web servicesдля обмена через JSON формат;

   6. Schedulers - Планировщики. Штатный функционал iDempiere, RPA процессы, которые запускаются по расписанию или, с небольшой модификацией, по событию, на отдельном служебном сервере приложений и делают своё дело. У вас могут быть сотни планировщиков, если это надо. В нашем случае планировщики проводят начисления бонусов по всем необходимым таблицам движения, еженощно сжигают устаревшие бонусы по методу FIFO, отслеживают и исправляют экзотические, проблемные транзакции (возврат приходит раньше продажи, например, из-за того, что моргнул интернет в магазине).

   7. Workflowengine - один из 2х встроенных движков автоматизации бизнес-процессов, может настраиваться на работу по событию, может пронизывать все ситуации, департаменты, сущности (читай - таблицы).

   8. Write to master database, report from hot replicasстандартная настройка, позволяющая отправлять все отчёты, включая автоматические, на одну или множество горячих реплик вашей базы данных;

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

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

Как в итоге всё работает?

1. В программе лояльности активировано уже 800'000 покупателей.

2. 99.9% из 300 магазинов имеют ту POS, которую имели до проекта.

3. Для магазинов был и написан, и описан минимально необходимый REST API, который и даёт почти мгновенную синхронизацию с централизованной программой лояльности.

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

5. POS-система в онлайне общается с этой централизованной бэк-офис системой всякий раз, когда вызывается программа лояльности. Даже слова и цифры из программы лояльности, которые нужно напечатать многоуважаемому покупателю/покупательнице на его/её кассовом чеке - передаются из центра (расшифровка акций в чеке, текущий статус в программе лояльности и т.д.).

6. В зависимости от сценария поведения покупателя (только начислять баллы или начислять-списывать) на одну продажу приходится до 3х транзакций обмена данными. Они занимают в среднем 50, 200 и 200 миллисекунд соответственно.

7. Бонусы, начисленные на только что состоявшуюся покупку, доступны для списания во время следующей покупки не позднее 1 минуты.

В этой статье описаны шаги по установке базы данных SAP HANA в домашних условиях. Основное отличие этого материала заключается в том, что мы не будем использовать традиционные виртуальные машины, такие как Oracle VirtualBox или VM Ware Workstation Player. В этом документе речь пойдет о новом подходе, разработанном компанией Microsoft, под названием Windows Subsystem for Linux.

Что же такое WSL? По сути, это новая функция запуска Linux с использованием облегченного подхода к виртуализации.

Вот прямое определение от Microsoft:

The Windows Subsystem for Linux lets developers run a GNU/Linux environment including most command-line tools, utilities, and applications directly on Windows, unmodified, without the overhead of a traditional virtual machine or dualboot setup.

Более детальную информацию о WSL можно получить на сайте Microsoft по ссылке.

В 2019 году появилась стабильная версия WSL2, которая получила ряд существенных дополнений по сравнению с первой версией. Основное отличие от первой версии - улучшенная производительность файловой системы, а также появившаяся полная поддержка системных вызовов ядра Linux. Ниже представлено сравнение двух версий WSL.

В этой статье мы сфокусируемся на установке SAP HANA Express Edition с помощью технологии WSL версии 2.

Итак, если вы использовали WSL версии 1, для установки SAP HANA вам придется обновится до версии 2. Также если вы используете версию Windows 1903 или 1909, вам придется или выполнить дополнительные шаги, описанные в документе, или обновить версию ОС, например, до 20H2.

Установка WSL2

Для установки WSL2 нам потребуется выполнить несколько шагов. Детальную информацию по установке можно получить по ссылке на сайте Microsoft.

Шаг 1

Включаем Windows Subsystem for Linux. Для этого запускаем PowerShell с правами администратора. В открывшемся окне вводим команду:

dism.exe /online /enable-feature /featurename: Microsoft-Windows - Subsystem-Linux /all

Шаг 2

Перед началом установки WSL2, нам необходимо включить опцию Virtual Machine Platform. Для включения этой опции вам потребуется поддержка виртуализации. Подробнее об этом по ссылке.

Для включения опции в окне PowerShell (с правами администратора) необходимо ввести команду:

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

После завершения компьютер необходимо перезагрузить.

Шаг 3

Скачиваем пакет обновления ядра LinuxWSL2 Linux kernel update packege for x86. Запускаем установку.

После установки переходим к следующему шагу, определению WSL2 как версию по умолчанию для новых инсталляций Linux.

Шаг 4

Установка версии WSL2 по умолчанию. Для этого в окне PowerShell вводим следующую команду:

wsl --set-default-version 2

Шаг 5

На этом шаге мы произведем непосредственно установку Linux. В Microsoft Store выбираем версию Linux. Я буду использовать OpenSUSE Leap 15.2. Нажимаем кнопку Get. Затем нажимаем Launch.

Подтверждаем сообщение о лицензии и добавляем пользователя. Всё, установка завершена!!!

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

Прежде всего воспользуемся командой:wsl --list v

Команда выводит название ОС и текущей версии WSL. Для отключения ВМ, необходимо в окне PowerShell ввести командуwsl --shutdown

Запуск ВМ можно произвести в окне поиска Windows. Вводим название операционной системы (в моем случае OpenSUSE).

Нажимаем правой кнопкой Запустить от имени администратора, вуаля, наша ВМ снова готова к работе.

Установка базы данных SAP HANA Express Edition

Вот, собственно, ради чего все мы все это и затеяли, а именно установка базы данных для разработчиков SAP HANA Express Edition .

Для начала скопируем дистрибутив на файловую систему нашей ВМ. Для этого нажимаем Выполнить и в открывшемся окне пишем:\\wsl$

В открывшемся окне выбираем нашу ВМ

И вот перед нами уже файловая система Linux. Просто и удобно!

Копируем дистрибутив и запускаем установку. Я произвожу установку с помощью hdblcm. Как видно на картинке ниже, я устанавливаю версию 2.00.045 (SPS 4). В настоящий момент это последняя доступная версия SAP HANA Express Edition.

Так как сама база данных, а также XSA (платформа для разработки) очень чувствительна к имени сервера, я буду использовать имя localhost (пункт Enter Local Host Name в установке). Или с помощью команды hostname можно определить название хоста на уровне ОС.

Сначала попытка установить базу данных, окончится ошибкой как на картинке ниже

Детали можно посмотреть в файле логов в каталоге/var /tmp /hdbinst .log. Ошибка связана с тем, что отсутствуют необходимые пакеты для ОС. Так как OpenSUSE идет из коробки, нам необходимо самостоятельно произвести обновление стандартных компонентов. Это можно сделать, выполнив командуzypperupdate, а также установить дополнительные пакеты, например numactl и libltdl 7. После этого установка базы данных прошла успешно.

На этом установка завершена. Теперь возвращаемся в Windows и подключаемся к базе данных через, например, SAP HANA Studio.

Не забудьте получить лицензию разработчика, это делается просто и бесплатно по ссылке.

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

Пока же у услуги доработка 1С под требования заказчика весьма и весьма мутный состав. Давайте возьмём лупу и прочитаем то, что написано мелким шрифтом.

Обучение стажёров

Ну, это прям на поверхности лежит и известно всем. Однако, упомяну.

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

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

Изредка встречается продажа стажёра, как стажёра. Например, клиенту говорят вот тебе придурошный новичок, знаний у него мало, но прыти хоть отбавляй. Бери его на 8 часов, оплатишь 1 час. Обычно под какую-нибудь работу, не требующую высокой квалификации, типа рисования бумажек, сверки остатков или вроде того.

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

Самая дурацкая затея покупать работу такого стажёра без предварительной оценки (сколько получится, столько получится). Получится много, при негарантированном результате. Обычно такой способ оценки работ используется, если надо разобраться, проанализировать или проверить, есть ли ошибки - в общем там, где от забора до обеда.

А вот покупать работу стажёра с предварительной оценкой, данной им самим, как ни странно, бывает выгодно. Он ведь и работать не умеет, и прогнозировать трудозатраты тоже. Как правило, называет стоимость ниже реальной, потому что не представляет, с чем имеет дело. Правда, вскоре начнёт переобуваться и просить увеличить стоимость работ, т.к. открылись новые детали (с высокой вероятностью просто открылся конфигуратор).

Комфорт Марины

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

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

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

Любой человек, когда его посылают, испытывает дискомфорт, и Марина не исключение. Поэтому она идёт к условному Никите, с которым танцевала на корпоративе и вместе ездит в маршрутке. Никита парень хороший, и специалист неплохой, но совсем в другой области. Например, по кассам, сканерам ШК, ЕГАИС и МДЛП. А Марина принесла задачу по планированию производства. Брать? Конечно. Не смотреть же в эти мокрые от слёз глаза. Да и учиться надо не век же ползать под столом у кассиров.

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

Если присмотреться к внутренней кухне франча, то подобных парочек, тройничков, foursome, а то и group *** обнаружится очень много. Всё бы ничего, но платит за эти оргии клиент. И неплохо бы этот ингредиент на упаковочке напечатать.

НДС

Это налог, только не на добавленную стоимость, а на дармоедов-специалистов. Одно из новшеств последних лет.

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

Программировать не умеет вообще. Ответить без подготовки на вопрос по программе (как это делает консультант) тоже не может. Умеет тыкаться в программе и, вроде как, писать ТЗ для программистов.

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

Для франча дармоеды хорошая затычка, когда надо делать хрен-пойми-чего (а сейчас такое часто бывает). Консультанта не отправишь он вечно занят, т.к. хороший конс редкость. Программисту лень сидеть и смотреть с пользователем в экран. А дармоеду самое оно.

Так что, если вы, как клиент, общаетесь с кем-то, кроме менеджера и программиста, можно предположить, что вам накинули НДС. Процент там, увы, далеко не 20.

Вакуум

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

Когда вы заказываете любую услугу по доработке или обслуживанию ПО 1С, будьте уверены на 99% - кто-то такое уже делал, причём в том франче, в который вы обратились. Но купите вы реализацию с нуля. И не потому, что так решили хитрозадые программисты 1С. Просто они понятия не имеют, что делают соседи и смежники.

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

Так что, в состав ингредиентов можно смело вносить каждый раз как в первый раз.

Маринад

Задачи, которые решают программисты 1С, частенько маринуются. Это специализированный процесс, призванный несколько увеличить стоимость итогового решения.

Например, обратился клиент за час до окончания рабочего дня. Так получилось, что нашёлся специалист, и решил задачу минут за 55 минут. Звонить, сдавать? Нафига. Оставляем до утра. И не говорим клиенту.

Если сдать сразу, то большее, на что можно рассчитывать 1 закрытый час. Если подождать до утра, то маринованная задача будет стоить уже 2, а то и 4 часа вопрос лишь в правильной подаче.

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

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

Текучка и ротация

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

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

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

А клиент ведь что частенько заказывает: доработку доработки. Он может об этом даже не подозревать, ведь текучка не только во франче есть человек видит программу, и хочет её улучшить. А кто там эту формочку рисовал, 1С или Никита ему параллельно.

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

Колобок

Чем больше франч и чем свежее клиент, тем больше он покатается по отделам, как колобок. Цель каждого отдела выжать из клиента максимум. И без разницы, что будет дальше там ведь вакуум.

Отдел продаж постарается впарить максимально дорогой продукт, лицензии с запасом на развитие, в идеале сервер и MS SQL (хотя есть бесплатный PostgreSQL), кучу сервисов и подпиской на максимальный срок, а заодно битрикс, куда ж без него. Подходит клиенту, не подходит без разницы. Внедрять-то будет другой отдел (если будет).

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

Сопровождение дружно кинется довнедрять и перевнедрять то, что они тут понаворотили. Рисуя клиенту ужасные перспективы работы с системой, содержащей такое количество недоработок.

До лисы докатится далеко не каждый колобок.

Отсутствие опыта к эксплуатации

Неочевидно, но невероятно. Как ни странно, во франчах крайне редко встречаются специалисты, обладающие опытом эксплуатации систем.

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

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

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

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

Тут я короче не знаю

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

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

Кратко смысл. 1С давно и неплохо ведёт список ошибок. Там всё чётенько в какой конфигурации, в каком месте, как проявляется ошибка, при каких условиях возникает, в каком релизе появилась, в каком исправлена, способ обхода (если есть).

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

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

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

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

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

Лень клиента

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

И тут имеет значение целый ряд факторов.

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

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

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

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

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

Что там в-шестых, в-седьмых и в-остальных, думаю, сами допишете.

Какой тогда вывод делаем? Всё хорошо, и я зря тут разнылся? Клиент получает тот состав ингредиентов, которого заслуживает? Кому надо, тот и колбасу хорошую найдёт, и программиста 1С? Или сам сделает?

Чё думаете?

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

Пока же у услуги доработка 1С под требования заказчика весьма и весьма мутный состав. Давайте возьмём лупу и прочитаем то, что написано мелким шрифтом.

Обучение стажёров

Ну, это прям на поверхности лежит и известно всем. Однако, упомяну.

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

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

Изредка встречается продажа стажёра, как стажёра. Например, клиенту говорят вот тебе придурошный новичок, знаний у него мало, но прыти хоть отбавляй. Бери его на 8 часов, оплатишь 1 час. Обычно под какую-нибудь работу, не требующую высокой квалификации, типа рисования бумажек, сверки остатков или вроде того.

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

Самая дурацкая затея покупать работу такого стажёра без предварительной оценки (сколько получится, столько получится). Получится много, при негарантированном результате. Обычно такой способ оценки работ используется, если надо разобраться, проанализировать или проверить, есть ли ошибки - в общем там, где от забора до обеда.

А вот покупать работу стажёра с предварительной оценкой, данной им самим, как ни странно, бывает выгодно. Он ведь и работать не умеет, и прогнозировать трудозатраты тоже. Как правило, называет стоимость ниже реальной, потому что не представляет, с чем имеет дело. Правда, вскоре начнёт переобуваться и просить увеличить стоимость работ, т.к. открылись новые детали (с высокой вероятностью просто открылся конфигуратор).

Комфорт Марины

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

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

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

Любой человек, когда его посылают, испытывает дискомфорт, и Марина не исключение. Поэтому она идёт к условному Никите, с которым танцевала на корпоративе и вместе ездит в маршрутке. Никита парень хороший, и специалист неплохой, но совсем в другой области. Например, по кассам, сканерам ШК, ЕГАИС и МДЛП. А Марина принесла задачу по планированию производства. Брать? Конечно. Не смотреть же в эти мокрые от слёз глаза. Да и учиться надо не век же ползать под столом у кассиров.

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

Если присмотреться к внутренней кухне франча, то подобных парочек, тройничков, foursome, а то и group *** обнаружится очень много. Всё бы ничего, но платит за эти оргии клиент. И неплохо бы этот ингредиент на упаковочке напечатать.

НДС

Это налог, только не на добавленную стоимость, а на дармоедов-специалистов. Одно из новшеств последних лет.

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

Программировать не умеет вообще. Ответить без подготовки на вопрос по программе (как это делает консультант) тоже не может. Умеет тыкаться в программе и, вроде как, писать ТЗ для программистов.

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

Для франча дармоеды хорошая затычка, когда надо делать хрен-пойми-чего (а сейчас такое часто бывает). Консультанта не отправишь он вечно занят, т.к. хороший конс редкость. Программисту лень сидеть и смотреть с пользователем в экран. А дармоеду самое оно.

Так что, если вы, как клиент, общаетесь с кем-то, кроме менеджера и программиста, можно предположить, что вам накинули НДС. Процент там, увы, далеко не 20.

Вакуум

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

Когда вы заказываете любую услугу по доработке или обслуживанию ПО 1С, будьте уверены на 99% - кто-то такое уже делал, причём в том франче, в который вы обратились. Но купите вы реализацию с нуля. И не потому, что так решили хитрозадые программисты 1С. Просто они понятия не имеют, что делают соседи и смежники.

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

Так что, в состав ингредиентов можно смело вносить каждый раз как в первый раз.

Маринад

Задачи, которые решают программисты 1С, частенько маринуются. Это специализированный процесс, призванный несколько увеличить стоимость итогового решения.

Например, обратился клиент за час до окончания рабочего дня. Так получилось, что нашёлся специалист, и решил задачу минут за 55 минут. Звонить, сдавать? Нафига. Оставляем до утра. И не говорим клиенту.

Если сдать сразу, то большее, на что можно рассчитывать 1 закрытый час. Если подождать до утра, то маринованная задача будет стоить уже 2, а то и 4 часа вопрос лишь в правильной подаче.

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

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

Текучка и ротация

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

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

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

А клиент ведь что частенько заказывает: доработку доработки. Он может об этом даже не подозревать, ведь текучка не только во франче есть человек видит программу, и хочет её улучшить. А кто там эту формочку рисовал, 1С или Никита ему параллельно.

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

Колобок

Чем больше франч и чем свежее клиент, тем больше он покатается по отделам, как колобок. Цель каждого отдела выжать из клиента максимум. И без разницы, что будет дальше там ведь вакуум.

Отдел продаж постарается впарить максимально дорогой продукт, лицензии с запасом на развитие, в идеале сервер и MS SQL (хотя есть бесплатный PostgreSQL), кучу сервисов и подпиской на максимальный срок, а заодно битрикс, куда ж без него. Подходит клиенту, не подходит без разницы. Внедрять-то будет другой отдел (если будет).

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

Сопровождение дружно кинется довнедрять и перевнедрять то, что они тут понаворотили. Рисуя клиенту ужасные перспективы работы с системой, содержащей такое количество недоработок.

До лисы докатится далеко не каждый колобок.

Отсутствие опыта к эксплуатации

Неочевидно, но невероятно. Как ни странно, во франчах крайне редко встречаются специалисты, обладающие опытом эксплуатации систем.

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

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

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

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

Тут я короче не знаю

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

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

Кратко смысл. 1С давно и неплохо ведёт список ошибок. Там всё чётенько в какой конфигурации, в каком месте, как проявляется ошибка, при каких условиях возникает, в каком релизе появилась, в каком исправлена, способ обхода (если есть).

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

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

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

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

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

Лень клиента

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

И тут имеет значение целый ряд факторов.

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

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

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

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

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

Что там в-шестых, в-седьмых и в-остальных, думаю, сами допишете.

Какой тогда вывод делаем? Всё хорошо, и я зря тут разнылся? Клиент получает тот состав ингредиентов, которого заслуживает? Кому надо, тот и колбасу хорошую найдёт, и программиста 1С? Или сам сделает?

Чё думаете?

В мире SAP эта платформа MOOC хорошо известна. Как они сейчас пишут на своём баннере: "5 millions course enrollments". Это если сложить все курсы, можно проверить, но это тема другого разговора.

Например: из недавнего был очень хороший курс Building Apps with the ABAP RESTful Application Programming Model. 25000 зачисленных это много, средний курс на платформе собирает примерно 5000-10000 зачисленных. Это в целом немного, а если с Coursera сравнивать - то эти цифры унизительно малы, впрочем миллионы регистраций на Coursera есть на курсах широкой специализации (типа Python), а тут у нас язык даже не из первой двадцатки TIOBE. В этом рейтинге ABAP сейчас находится на 35 месте с долей 0.35%. Совпадение чисел - действительно совпадение.

Кстати, давайте посчитаем если у Python 11,03% против 0,35% у ABAP, то это означает 30-кратную разницу. Значит 25000 регистраций ABAP сравнимо было бы с 750000 регистраций у Python. Очень достойный результат.

Большое отличие платформы OpenSAP - курсы полностью бесплатные только в момент запуска. По завершении курса бесплатная карета превращается в бесплатную тыкву, примерно такую же как Аудит у Coursera. То есть: нет тестов и сертификата, можно только "смотреть видосики в интернете".

Для меня режим "аудит" часто не подходит, так как отсутствие кнута(тестов) и пряника(сертификата) существенно снижает мотивацию и концентрацию на материале.

Есть один интересный курс на Writing Testable Code for ABAP, я его пропустил в своё время. А за реактивацию (превращение тыквы обратно в карету) они обычно просят $59, с редкой 50% скидкой по праздникам. В прошлом году в честь сами-знаете-чего-когда-все-стали-сидеть-дома OpenSAP открывали обратно за бесплатно многие свежие курсы, но этот конкретный курс под акцию не попал.

Если вам жалко столько денег, то есть метод получить один курс бесплатно на выбор.

Для этого надо пройти курс SAPs Integrated Intelligent Suite, вполне годный обзорный курс. Этот курс надо завершить и запостить об этом запись в твиттере с правильными хештегами (подробности в описании самого курса). Для этого даже завёл себе аккаунт в твиттере: я способен и на такие непотребства, если это сэкономит мне целых $59. И вот примерно через месяц пришло письмо счастья с кодом для реактивации, который я знаю куда применить.

Следите за обновлениями на OpenSAP, ловите интересные курсы, пока они бесплатные.

Например: буквально завтра уже запускается курс Efficient DevOps with SAP. Налетай!

Краткое содержание:

• Week 1: Introduction to DevOps

• Week 2: CI/CD with ABAP (On-Premise)

• Week 3: Delivery of Cloud Applications

• Week 4: Hybrid Change and Test Management

• Week 5: Operation of Your Solution and Summary

• Week 6: Final Exam