Поиск в системе

Последние полгода выдались для нашей команды очень насыщенными с точки зрения желания клиентов стартовать и финишировать проекты автоматизации самого разного масштаба, разных предметных областей (складские процессы, учет и управление производством, трейд-маркетинг, управление процессами формирования задания на производство) и разных видов производства (сыроделы, мясо-переработчики, цельномолочное производство). Мы, как интеграторы, из раза в раз наблюдаем схожие ситуации, касаемо выбора партнера и ИТ-решения (в т.ч. и порой очень рискованные). Поэтому сегодня хочется поделиться своим опытом о том, какие виды помощи на рынке сможет получить потребитель, решивший внедрить автоматизированную систему на своем производстве, кому подходит каждый из этих вариантов, а кому – нет. На чем строится успех проекта? Прежде чем рассуждать – что может предложить современный рынок аутсорсеров для выполнения проектов автоматизации, обратим внимание на важный факт: Успех вашего проекта строится на совокупности следующих факторов: грамотная предпроектная подготовка в виде формализации требований к целевым процессам (не «как есть», а «как надо») и их настройке в автоматизированной системе выбор подходящей платформы и конфигурации для автоматизации подбор квалифицированной команды исполнителей на доработку-настройку-внедрение выбранного ПО Понятно, что в любом проекте автоматизации есть множество нюансов, которые влияют на его успешность. Однако в данном материале позволю себе упростить «рецепт успеха» и ограничиться только наиболее критичными моментами. Какие виды помощи существуют на рынке? Собственно, на практике из описанных выше элементов чаще всего и складывается то или иное предложение помощи в автоматизации: консалтинговые услуги продажа программного обеспечения помощь по разработке/внедрению автоматизированных систем Разберем чуть подробнее каждый из них. Консалтинговые услуги Разработка предпроектной документации, которая будет являться неким «ТЗ» (как минимум, описания целевых бизнес-процессов, требований к автоматизации в системе, к управлению проектом и т.д.) для будущего внедрения и на основании которой можно будет посчитать план-график работ и бюджет внедрения. Кому подходит Тому, кто знает свои текущие процессы («как есть»), но не знает – как описать целевые требования к проекту («как надо») с учетом всех нюансов такого сложного процесса. Основные ошибки на практике Часто приходится сталкиваться с двумя случаями весьма упрощенного и рискованного подхода: «ТЗ» описывается самостоятельно людьми, которые чаще всего впервые выполняют подобную работу и это получается просто набор «хотелок», которые еще дорабатывать и дорабатывать, чтобы их можно было использовать как основной документ для проекта автоматизации. Предпроектные работы отдают будущему партнеру-франчайзи, не убедившись, что он является экспертом в пищевой отрасли («они же понимают в «1С», а мы нет»). В итоге часто предпроектный документ (иногда просто нечитабельный) – это многостраничное описание того, как можно в той или иной конфигурации 1С настроить процессы в выбранной заказчиком предметной области. Вот и получается в итоге «разговор немого со слепым»: заказчик не понимает в ИТ, а аутсорсер – в специфике пищевого производства. Итог: проект, начавшийся по такой документации, заходит в тупик и сильно отклоняется от сроков-бюджетов. А реальные требования вырабатываются прямо по ходу (что влечет множественные переделки в проекте и трату времени и нервов обеих сторон). Продажа ПО + опционально его настройка под требования заказчика (без внедрения в промышленную эксплуатацию). Кому подходит Подготовленному Заказчику, который: знает, какая у него должна быть архитектура информационной системы понимает, какая конфигурация 1С ему нужна и как ее следует настроить/доработать, чтобы получить необходимый бизнесу инструмент готов самостоятельно управлять процессом внедрения разработанного инструмента в жизнь Основные ошибки на практике Заказчики смотрят на автоматизацию, как на процесс покупки и внедрения некоей волшебной программы (особенно если она отраслевая, напр., какая-нибудь «1С:Нужное нам производство»), где уже есть вся логика работы, осталось только внести нужные данные и начать работать с ней работать. А большинство программных продуктов на «1С» — это набор кирпичей, а не готовое здание)) Вот и получается, что программа куплена, как-то настроена и даже какие-то данные внесены, но все работает не так как надо. И тогда все же приходится возвращаться к этапу обдумывания – ЧТО и ДЛЯ ЧЕГО мы хотим? А потом снова проходить этап настройки/доработки системы. При этом встречаются 2 распространенных варианта развития событий: После покупки ПО нагрузка по разработке и внедрению системы ложится на плечи своих и так перегруженных ИТ-ков. При этом методологической поддержки со стороны бизнес-заказчика им не оказывается («мы же в 1С ничего не понимаем). А своего понимания предметной области нет + нет опыта управления проектом внедрения + «нет пророка в своем отечестве» и их указаний по использованию переданного ПО не слушаются. Вот все и встает колом. Партнера берут без учета его понимания предметной области автоматизации и опыта решения подобных задач, а по принципу удобства (напр. «они у нас уже бухгалтерию обслуживают»). Выбранная компания-внедренец легко соглашается задешево «внедрить программу», а потом доказывает клиенту, что полученный недорезультат – это именно то, что хотел клиент. А то, что она работает не так или не удобна в использовании, так это легко переделать. Надо только доплатить и сказать – что надо сделать)) И так по кругу. В добавок заставить своих сотрудников работать с этой программой – это тоже задача самого клиента (ведь подрядчик отвечает только за разработку и настройку программы). Проектное внедрение «под ключ» Разработка предпроектной документации, выбор корректной архитектуры ИС, настройка-доработка системы, внедрение системы в промышленную эксплуатацию до получения гарантированного результата, интересующего заказчика. Кому подходит Тем, кто заинтересован в получении гарантированного результата. Причем, знает/понимает – какой именно результат интересует. Нет собственных ресурсов для выполнения такого проекта или есть ограничения по времени для выполнения проекта. Основные ошибки на практике 1. Чаще всего интегратор привлекается из компании, «понятной» или укладывающейся в ценовые ожидания заказчика, но без отраслевого опыта автоматизации пищевых производств (бухучет не в счет) или без опыта управления крупными проектами. Впрочем, попадаются и внедренцы с однократным опытом внедрения у пищевиков («мы уже делали это у завода N, сделаем такое же и вас»), но повторение однократного опыта не дает понимания специфики отрасли и гарантий, что одна и та же система будет одинаково хорошо работать у обоих предприятий. 2. Заказчик надеется, что широко разрекламированное флагманское решение от «1С» (типовое или отраслевое) «выправит руки» подрядчикам и дешевые специалисты, но с «хорошим продуктом» сделают качественный результат. Практика показывает, что такие ошибки дорого обходятся заказчикам. Впрочем, в одной широко известной поговорке про скупого уже все было сказано давно. 3. Редко встречающийся, но все же имеющий место быть вид «шероховатых» внедрений – привлечение партнера «1С» с известным федеральным брендом. Вроде как заказчик через это сможет получить доступ к компетенциям всей сети, и известный внедренец точно вытащит наш проект. Только вот на практике доступ к реальным специалистам могут получить только самые крупные и важные для такого внедренца клиенты, а остальным приходится довольствоваться местными «спецами» без нужного опыта и компетенций. Причем такие компании с федеральным брендом часто подстраховываются и заранее согласовывают с Заказчиком – что есть результат проекта (причем заказчик, не зная, что ему на самом деле нужно, соглашается с этим), чтобы избежать разногласий и выхода за рамки бюджета. Только что потом делать, если в конце проекта получается, что формально, т.е. по договору результат сделан, а работать с ним невозможно? Впрочем, у заказчика всегда есть право поменять свое мнение и доплатить за доработку своих новых хотелок)) Вот тебе и «федеральный бренд»… На что обращать внимание? Для повышения степени успешности вашего проекта автоматизации рекомендуем на этапе подготовки к проекту сделать следующие шаги: Оценить необходимость проведения предпроектных работ Если у вас процесс, который вы хотите автоматизировать работает «как часы» и не требует никаких оптимизаций-коррекций, а только перенесения в автоматизированный вид, то вам требуется только тщательно проработать структуру работ, подобрать нужное ПО, определить роли исполнителей и назначить их. В остальных других случаях надо хорошенько продумывать «дорожную карту» проекта и порядка его выполнения. Провести анализ существующей информационной системы на предприятии и программных решений на рынке на предмет того – насколько они обладают необходимым функционалом (типовым или отраслевым) и будут удобны для внедрения и дальнейшего сопровождения Желательно опираться при этом не на рекламные обещания продавцов (они явно заинтересованы в продаже) и мнения знакомых, которые не учитывают вашей ситуации, а транслируют только свое мнение о своей ситуации. Практика внедрений и использования на аналогичных и сопоставимых с вашим предприятием – вот это похоже на какую-то гарантию. Оценить способности потенциальных внедренцев системы – своего специалиста (если собираетесь делать своими силами) или внешнего партнера по внедрению. Кроме понятных для большинства критериев оценки проекта (через время исполнения и деньги) надо бы оценить другие важные факторы. Например, честно для себя ответить на вопросы: есть ли у потенциального исполнителя необходимые знания и опыт по автоматизации интересующей вас предметной области (причем не только и не столько с технической точки зрения знания «1С», а больше с точки зрения понимания отраслевой специфики и бизнес-целей проекта)? сможет ли он управлять сложными проектами разработки и внедрения информационных систем (если считаете, что сможет, то определите – за счет чего?) есть ли у него ресурсы для выполнения проекта Вместо завершения Если вы проделаете указанные выше шаги, то с большей долей вероятности вы уже более трезво сможете оценить — какой вариант внедрения подходит именно вашей компании? Ну а если что-то (время, горящие рабочие задачи, правительство, отсутствие знаний в указанных областях и т.д.) не позволяет проделать указанные выше шаги, и вы все еще сомневаетесь в выборе, то всегда можете обратиться к нам. Как минимум для обсуждения вашей ситуации и определения подходящих вариантов. А то искренне жалко наблюдать как из-за неверно принятых решений выбрасываются на ветер время, деньги и людские нервы. Прям за себя иногда обидно, что не смогли уберечь людей от этого. Обещаем помочь если не делом, то советом точно!

Регулярно в ходе наших проектов мы сталкиваемся с очень важным вопросом – организацией IT-ландшафта. И традиционно сразу образуется 2 лагеря: сторонники одной большой информационной системы («лучшая интеграция та, которой не было») и сторонники использования нескольких отдельных информационных систем («под каждого воробья пушка своего калибра»). У каждого из этих подходов есть свои плюсы и минусы, которые мы не будем глубоко затрагивать в рамках этой статьи, однако попробуем раскрыть тему. Как жить безопасно, если интеграции все-таки быть? Если все-таки сложилась ситуация, при которой в нашем IT-ландшафте будет несколько различных информационных систем, то при проектировании этой схемы необходимо предусмотреть методологические аспекты: каким образом мы будем нарезать наши бизнес-процессы таким образом, чтобы они и работали органично (когда на каждом этапе в информационной системе выполняются только те операции, которые должны выполняться) и обеспечивали достаточно целостное информационное пространство, в котором работают пользователи. Попробуем разобрать традиционную для производителей продуктов питания задачу – организацию документооборота с клиентами. И выявить правильные и не правильные способы ее решения. Распространенный вопрос: отделять логистический контур от финансового или нет? Неправильная схема разделения: В логистическом контуре выписываем документ реализации, затем он выгружается в финансовую базу. После возврата документов от клиентов мы начинаем редактировать их в базе финансового учета. И при редактировании у нас получаются изменения, которые влияют на остатки товаров, важные для логистического контура. На лицо нарушение одного из базовых правил – объект должен создаваться и редактироваться в одном месте. Пример правильной схемы разделения: Документы реализации создаются и редактируются в своем контуре, затем за какой-то завершенный период (день, неделя, месяц) документы выгружаются в контур фин. учета. Таким образом получается, что документы создаются и редактируются в одном месте, а база фин. учета является потребителем выверенной информации логистического контура. Если мы методологически грамотно разделили информационные потоки – это уже очень весомый вклад в то, что системы будут функционировать нужным образом. Но у нас так же остается достаточно серьезный вопрос Техническая организация обменов Чтобы не ошибиться с выбором механизма интеграции, необходимо сначала определиться с «калибром»решаемой задачи. Итак, можно выделить 4 уровня ее масштабности: Локальный – характеризуется обменом через внешние файлы. Данный механизм мы относим к классу устаревших, но тем не менее ранее он был достаточно распространен и с некоторыми ИС является единственным доступным вариантом интеграции. Регулярный в однородных средах – подразумевается, что интегрируемые ИС находятся в одной информационной среде. Например, на одном сервере, обмениваются через COM. Такой механизм на текущий момент достаточно часто встречается и позволяет решать задачи интеграции регулярного характера. Его удобно реализовывать, когда у нас имеется относительно небольшое количество ИС. Преимуществом такого подхода является очень легкая настройка и создание программного интерфейса, которым будут пользоваться интегрируемые системы. Регулярный в гетерогенных средах – подразумевается, что интегрируемые ИС могут располагаться на разных серверах, с разными ОС, даже территориально обособлено. Речь идет об обмене через web сервисы. Одно из преимуществ такого подхода – возможность интегрировать базы в различных средах, при этом сохраняя относительно невысокую сложность настройки интеграции. Промышленный – применение отдельно стоящих решений в гетерогенных средах: шины ESB (например DATAREON) или промышленный сервер очередей (например RabbitMQ). Такие решения актуально применять, когда в обмене участвуют более 3-х ИС, когда важно обеспечить качественную передачу НСИ между всеми системами, и когда важно балансировать нагрузку между обменивающимися ИС. Инструменты проверки Когда мы решили первые 2 вопроса в нашем пути интеграции, настает время подумать о поддержке эксплуатации ИС в части интеграции. И здесь встает вопрос о том, чтобы можно было в 1 информационном пространстве сверить данные 2-х интегрируемых систем. Как один из примеров – анализ отгрузок в базах фин. учета и логистического контура. Здесь мы так же выделяем 2 подхода: Пассивный – когда ответственный за участок учета пользователь формирует отчет, который позволяет сравнивать данные за идентичный период в 2-х базах и предпринимать какие-то действия в случае расхождений Активный – когда есть некий анализатор, который регламентно получает 2 набора данных из разных баз, сравнивает их и в случае расхождения оповещает ответственного. Таким образом, если вы планируете строить не просто систему автоматизации фин. учета, а систему управления, в том числе и на оперативном уровне, то вы неизбежно придёте к архитектуре нескольких информационных баз. Наиболее успешные из автоматизированных предприятий потому и являются таковыми, что вовремя осознали ценность концепции микросервисов (когда небольшие отдельные ИС решают узконаправленные задачи), ведь выиграть в конкурентной борьбе им смогли помочь только специализированные решения, которые заточены под их особенности и способны достаточно оперативно реагировать на изменения среды. Именно на примере этих компаний мы понимаем, что для реализации таких подходов требуются надежные и удобные для внедрения и эксплуатации средства интеграции IT систем. P.S.: Интеграция – это задача, а вовсе не проблема. И, при современном уровне ее осмысления и наборе технического инструментария - больше, чем решаемая.