Просматривая страницы на Хабре, я наткнулся на переводную статью о SAP (2020), из которой ещё была ссылка на статью из web.archive.org, когда-то тоже бывшую на Хабре (2015).
Прочтение статей мысленно перенесло меня в 2003 год.
Тогда я успешно продвигался из с состояния инженера-программиста в состояние заместителя директора по автоматизации систем управления. На рабочем месте стояла машинка под управление PTS-DOS, в которой был офис, электронные таблицы, система Гарант, браузер, аудио и видео проигрыватель. Изменение сетевых протоколов в Windows Serwer 2003 заставило достаточно быстро сменить её на более современную. Достаточно активно расширялась локальная сеть, создавались новые рабочие места.
Предприятие было автотранспортным. Начало внедряться удалённое диспетчерское управление перевозками посредством систем GPS (позднее GPS/Глонасс).
Система ERP с текстовым интерфейсом существовала тогда уже несколько лет (компания её разработчик до настоящего времени здравствует).
Возникла необходимость создать систему управления ремонтами. На тот момент это надо было делать быстро, а потребность возникла не только у нашего предприятия. Специалисты нескольких родственных предприятий взялись за разработку систем, чтобы затем коллективно выбрать ту, что внедрится у всех.
Одна из успешных разработок была создана на базе MS Access. На тот момент это была современная и удобная система для быстрой разработки баз данных и управления ими. Я сам принимал участие в её разработке, и именно она работала на нашем предприятии.
Система была удобной и легко расширяемой. Я тогда создавал интерфейсы для производственных участков, где работали люди не знающие, что такое компьютер. Представьте себе посменно работающих пенсионерок на складе оборотных (прошедших ремонт) запасных частей. У этого интерфейса тогда было условное название — «интерфейс для бабушек».
Создавались интерфейсы для ремонтных участков, где работали молодые ребята слесаря. Для минимизации ошибок разработка велась с их помощью. Предварительные версии интерфейса обкатывались на тестовых задачах оператором слесарем.
Этот интерфейс в руках слесарей позволил выявить партию поставленного навигационного оборудования с однотипным дефектом, из-за которого это оборудование регулярно приходилось отправлять в ремонт.
Само диспетчерское управление строилось на основе взаимодействия диспетчеров предприятия и удалённой центральной диспетчерской созданной для обслуживания нескольких предприятий. Туда стекались все навигационные данные, сравнивались с расписаниями движения, формировались данные о транспортной работе, простоях, авариях и пр.
Я тогда создал небольшое скриптовое приложение, которое передал в центральную диспетчерскую, чтобы при появлении в их базе обработанных данных, приложение пересылало их на наш сервер по почтовому протоколу через выделенную линию модем-модем (ещё невозможно было создать общую базу данных) . Тогда интернет ещё только начинал становиться тем что мы видим теперь. Сервер обнаруживал новые данные, предварительно обрабатывал и передавал в группе таксировщиц, которые увидев эти данные в своих интерфейсах начисляли зарплату водителям, фиксировали нарушения. На основании данных о нарушениях автоматически готовились приказы о наказаниях. Данные о начисленной зарплате и использовании горючего попадали в бухгалтерию.
Главный инженер предприятия имел у себя свой интерфейс, который помогал контролировать ход ремонта техники, задержки выпуска из ремонта, причины.
Это всё работало уже в 2004 году.
На предприятии не применялись ни 1C, ни другие существующие тогда системы кроме одной исторически прижившейся (ERP упомянутая выше), хотя поиск их выполнялся. Ни одна из предлагаемых тогда на рынке систем не могла обеспечить все требования предприятия.
Коллективные внутренние разработки подошли к завершению и было созвано большое совещание, на котором можно было посмотреть на результаты. Несколько представителей рассказывали о преимуществах и недостатках своих систем. Оставалось проанализировать увиденное и выбрать то, что можно применить на всех родственных предприятиях, принять решение о необходимости доработок. Всё это выполнялось за зарплату.
Верхнее руководство тоже со своей стороны вело поиски, которые привели к приходу на предприятие разработчиков систем на основе SAP R3.
Я не буду подробно рассказывать о технологии внедрения. Скажу только, что новые разработчики не смотрели на то, что уже работает, говоря, что они сами знают как это должно работать. Пришлось увеличить штат бухгалтерии. Многие рутинные операции требовали теперь повышенного внимания и стали выполняться существенно дольше. Для внесения изменений в технологические процессы связанные с изменениями в законодательстве необходимо стало писать заявки с подробным изложением требований законодательства. Мои попытки вывести на публичное обсуждение возникающие проблемы привели к закрытию сайта предприятия под угрозой увольнения нашего директора.
Процесс внедрения тянулся более двух лет. Стоимость сопровождения системы при этом выросла в десять раз.
Если бы все родственные предприятия были коммерческими, они просто разорились бы. Но они были государственными.
Довольны остались только те предприятия, где вся работа до внедрения SAP велась вручную.
После внедрения системы были ликвидированы отделы компьютерного обеспечения, как они тогда назывались, а также должности заместителей директора по автоматизации систем управления.
Что происходит в наше время?
Я давно уже не работаю в той системе, но знаю через оставшихся сотрудников о том, что идёт поиск способа уйти от SAP. Рассматривается даже 1C. Теперь это очень сложно и дорого. Переносить базу данных из одной системы в другую, задача не простая, а собственных специалистов способных это сделать не осталось.
Ничего не могу сказать против необходимости применения современных IT-решений. Но если внедрение происходит силовым методом, возникают непредвиденные расходы и проблемы.
Интересно было бы в комментариях прочитать о внедрении нового в наше время. Происходит ли это силовым методом, или на основе здравого смысла. Какие выгоды приносит замена работающего, но старого, на новое программное обеспечение? Как происходит выбор этого нового?
Комментарии (14)
saipr
02.03.2022 16:48Прочтение статей мысленно перенесло меня в 2003 год.
И вот я уже в 2002-2005 годах и тоже имею дело с SAP AG. Золотое было время. Российское отделение SAP AG возглавлял Марко Бурхард, очень грамотный руководитель. Если он видел в собеседнике специалиста, а не попрошайку, то он всячески шёл на встречу. В то время у нашего коллектива возникла идея, которой проникся и Бурхард, встроить российскую крипрографию в системы от SAP. Речь шла о протоколе реализация протоколах SSF (Secure Store and Forward) и SNC (Secure Network Communications), а также об https.
В итоге эти задумки не только были реализованы, но и прошли успешную сертификацию в сертификационном центре SAP в Вальдорфе (почти что Северный поток-2):В системах стало возможным использовать российскую криптографию как для электронной подписи, так и для шифрования. Всё это по сегодняшнего дня успешно используется в АОА "РЖД".
Тогда казалось, что вот оно это международное взаимовыгодное сотрудничество. Но оказалось, что это было просто счастливое время. Сегодня наступила эпоха импортозамещения, на первый план выходит 1C...
dyadyaSerezha
02.03.2022 19:56Году в 15-ом мы мнедряли одну картографическую систему в наш продукт, но главный архитектор был настолько помешан на гибкости, что код универсального единого map API, к которому предполагалось прицлять разные системы (кроме выбранной), превысил код собственно самой предметной области. Все сроки были превышены многократно, дальше не знаю, ушёл оттуда.
Mustard
02.03.2022 21:33Сейчас даже переход с 1С на 1С представляет существенную проблему: время, сложность разработки и требования к специалистам возросла в разы. То, что успешно работало ранее «из коробки» в новых системах заявляемых, как флагман, типа 1С:ERP просто отсутствует, как класс; логика процессов в новых системах переработана людьми далекими от реального бизнеса, мыслящих абстракциями и стремящихся к полной универсальности. В той же самой 1С:ERP раз в 2-3 года полностью пересматривается архитектура, что создает огромные проблемы, как для пользователей, так и для разработчиков. Огромное количество ошибок не исправляемых годами.
Beard-56 Автор
02.03.2022 22:03Спасибо за информацию. Но есть вопрос:
«логика процессов в новых системах переработана людьми далекими от реального бизнеса, мыслящих абстракциями и стремящихся к полной универсальности» — значит ли это, что теперь программист выполняет требования «успешного менеджера» и уже не может отвечать за результат своей работы?Mustard
02.03.2022 22:13Я наверное немного погорячился, конечный продукт это результат работы команды от непосредственно разработчиков до тестировщиков. Но лично у меня складывается впечатление, что многие модули делаются под конкретных заказчиков некоторых дочек 1С окучивающих целые сектора и потом просто адаптируются на тиражные решения. Вцелом, то что раньше можно было за час, сейчас занимает 10 и это при прочих равных условиях погруженности в предметную область и прочие скиллс.
Plovchik
03.03.2022 08:13Спасибо за статью. Ничего не поменялось.
Но мне кажется небольшой частный бизнес еще может руководствоваться здравой логикой и выбирать модели апгрейда основываясь на цена/качество или что то дорабатывать даже самостоятельно, силами сотрудников. Крупные корпорации выбирают же методы решения проблем основываясь на делегировании таких задач подрядным организациям. Находим подрядчика пожирнее да по опытнее, заключаем контракт, перечисляем кучу денег предоплатой. Подрядчик особо не торопится, срывает сроки и пытается раскрутить на доп. функции. Периодически пушим его. Если подрядчик порядочный все делает в срок, то Вы молодец раз нашли такого и успешно внедрили новый процесс. (Премия Ваша) Если подрядчик тормозит, то что Вы можете сделать, ведь это лучшее что есть на рынке и вообще Вы не виноваты и делаете все что в Ваших силах (Премия Вам за старания)
Не IT-спец, но сам столкнулся с таким. Компания почему то готова заплатить сторонней организации кучу денег за определенную услугу, но не мне за то же самое)
Beard-56 Автор
03.03.2022 08:47Спасибо за информацию.
Компания почему то готова заплатить сторонней организации кучу денег за определенную услугу, но не мне за то же самое)
Я так понимаю, что здесь возможны три причины.
1. Кредит доверия.
Руководство больше доверяет организации, чем частному лицу.
2. Откат.
Вы не можете предложить руководству компании ничего кроме выполненной работы. А подрядчик мог оплатить «входной билет».
3. Наличие конкурсной процедуры. Разработчик принял участие в конкурсе и выиграл, а Вы нет.
Girafa01
Ничего не меняется. Все так как Вы и описывали. Был программист, который разработал систему проверки документации, которая была очень удобной, быстрой и еще куча +.
Когда он увольнялся, никто и не спросил, что да как в ней было сделано...
Теперь вся контра сидит в xls. Вроде то же самое, но выйти некуда...
Beard-56 Автор
Раньше именно такие ситуации приводили к отказу от местных разработок. Но у нас были разработки хотя и местные, но коллективные. Код не мог пропасть при увольнении одного человека.
PereslavlFoto
В одном случае всё зависит от сотрудника, риск в его увольнении.
В другом случае всё зависит от поставщика, риск в его громоздкости.
Оба варианта плохие. Где же хороший вариант?
Beard-56 Автор
Вот и интересует меня опыт уже внедривших или внедрявших. Только на опыте можно делать выводы о плохом или хорошем варианте.