Search the Community
Showing results for tags 'ит-решения'.
Found 2 results
-
Зачастую, принимая решение об автоматизации интеграции с ГИС Меркурий и воплощая эту самую интеграцию в жизнь, задача рассматривается как буквальная — обеспечение фактической способности передачи данных об отгружаемом товаре. Просто и безапеляционно. Нужно передавать данные, так мы и передаем. Но стоит задуматься о том, насколько успешен такой подход, и почему послевкусие от таких внедрений оставляет желать лучшего? Делимся: По опыту многих внедрений становится понятно, что по настоящему приносить пользу может только комплексное решение по автоматизации ряда процессов, предшествующих самой передаче данных в Меркурий. Решение, которое делает проще работу не только (и не столько) по передаче информации, но по её аккумуляции. А структуру передаваемой информации более обширной и полезной для конечного клиента, получающего отправленное нами ЭВСД. Конкретнее: Так почему же нельзя автоматизировать исключительно интеграцию с ГИС Меркурий, не автоматизируя прилегающие процессы? (Ответим, рассмотрев каждый процесс с точки зрения его влияния на участие в формировании требуемой информации). О каких процессах идёт речь? Автоматизация процессов маркировки групповой упаковки и логистических мест Автоматизация фиксации выпуска на этапе маркировки Автоматизация списания сырья в производственной партии Автоматизация складских процессов, в частности, наборка продукции в разрезе партий Автоматизация элементов функций транспортной логистики Как их автоматизация влияет на аккумуляцию данных в системе (в разрезе необходимых аналитик для передачи в ГИС Меркурий)? Хочется рассматривать эти процессы совместно и в рассмотрении идти с конца цепочки. Данные в Меркурий должны быть переданы в разрезе партий продукции (а в некоторых случаях и в разрезе логистических мест и упаковок). Залогом того, что в Меркурий будут переданы данные ровно о той продукции, которая фактически отгружена со склада, может быть только автоматизированный учёт наборки. Чаще всего, используется считывание штрих кода с упаковки продукции или логистической единицы. Во всех остальных случаях — ручной ввод. А ручной ввод — это надежда на острый глаз и трезвый ум вводящего, что, вероятно, не надёжно. Собственно для того, чтобы штрихкод был считан, он конечно же должен быть нанесён. И не абы-какой, а позволяющий проидентифицировать не только сам товар, но и его партию и дату производства. С учётом регулярно меняющихся требований по составу этого штрихкода, управляемость возможностью редактирования этикетки становится насущной необходимостью. Применение типографской этикетки становится неприемлемым. Прежде чем на продукцию будет выписано исходящее ЭВСД, она конечно же должна быть произведена. Гарантией попадания достоверной информации о выпуске в Меркурий может служить своевременная фиксация в учётной системе факта выпуска готовой промаркированной продукции. Тогда мы гарантированно сможем передать информацию для формирования соответствующей производственной партии в Меркурий. И да, стоит отметить, что выпускать продукцию в Меркурии “из ничего” уже не модно. И не модно и неудобно! Гораздо удобнее задать спецификацию с пропорциями потребляемого сырья на конкретный вид продукции и наслаждаться его автоматическим распределением в производственной партии. Вот и получается, что управляемо отмаркированная, вовремя выпущенная и правильно проидентифицированная на этапе наборки продукция существенно упрощает получение информации, в структуре удобоваримой для передачи в ГИС Меркурий. Делаем выводы: Результат адекватной работы автоматизированных процессов, о которых мы ведем речь выше — стройно собирающаяся в системе информация, в том виде, в котором её можно легко потреблять. В этом случае её передача в ГИС меркурий становится делом техники. Если вы то же почувствовали в себе потребность сделать систему не только удовлетворяющую внешним требованиям, но и удобную в использовании и вам требуется помощь…. Обращайтесь. Мы так умеем) -
В середине 2000-х при выборе платформы ИС большинство производителей продуктов питания остановились на 1С УПП. И за последние 10-15 лет построили и, можно сказать, «вросли в нее корнями» (будь то чистое 1С УПП или отраслевое решение на его основе). Кто-то старался активно развивать все в одной информационной базе, кто-то разделять функционал подразделений в разные базы. Но, как ни крути, УПП была и остается центральным элементом выстроенной системы, т.к. консолидирует в себе все транзакции финансово-хозяйственной деятельности предприятия. И ничто не предвещало беды, пока несколько лет назад на рынке не стала систематически появляться информация о том, что поддержке УПП скоро придет конец. Конечно, интерпретировать эту информацию и определять масштаб бедствия все стали по-разному. Однако, большинство пользователей 1С:УПП сформировали у себя «чемоданное настроение» и на рынке появилась тенденция движения в поиске нового решения. Вопрос: на что переходить?Стандартный ответ: конечно на 1С:ERP. Но здесь надо понимать, что, когда компании начинали развивать свою систему на базе УПП, масштаб, скорость развития и степень автоматизации бизнеса были совсем другими, а уровень ИТ-кадров вообще практически никакой. Когда-то автоматизации бухучета всем казалось достаточно. Сейчас ИС стали действительно важным элементом поддержки бизнес-процессов, а в бизнесе появились люди, которые отвечают за ИТ профессионально. И они осознают, что ИТ-система – это не просто программка, которую можно поменять с одной на другую (как например, мобильный телефон, переставив сим карту) и решить этим все свои проблемы. Смена платформы – это совсем из другой оперы. При этом даже грамотный ИТ-специалист не всегда знает, как перейти с платформы А на платформу В. Особенно если известно только «А» (и то не всегда :)), при том, что целевое состояние «В» пока находится в тумане. Вот откуда возникает потребность в разработке концепции развития ИС. По опыту выполнения подобных работ мы выработали для себя технологию выполнения этой задачи. И в рамках данного материала хотим поделиться этой технологией с вами. Из чего состоит «Концепция развития ИС»? Последовательность шагов 1. Построение организационной структуры ИС поддерживает деятельность подразделений внутри компании (каждого в отдельности и взаимодействия между ними). Соответственно перед тем, как понять, какой должна быть ИС, мы должны выяснить, какие функции есть у бизнеса и какие из них должны быть автоматизированы. Ответ на этот вопрос дает организационная структура компании. Однако не во всех компаниях та структура, которая есть на бумаге, соответствует реальному положению вещей. Именно поэтому речь идет не о том, чтобы взять за основу существующий документ, а о том, чтобы определить уровень его актуальности на сегодняшний момент времени. И если есть расхождения, сформировать новый. 2. Формирование набора ИТ задач, соответствующих каждой функции бизнеса. У каждой из функции бизнеса есть потребность в конкретных ИТ задачах. Часть этих задач могут быть уже решены, часть – нет. По каждой задаче надо оценить, на сколько реализация соответствует текущим потребностям бизнеса. И если не соответствует, то какие целевые ориентиры развития мы имеем. При этом надо опираться на потребности пользователей, которые непосредственно работают с данной ИС с одной стороны, и отраслевых экспертов — с другой. Сверка с отраслевой практикой позволит покрыть белые пятна, которые не видят функциональщики и отфильтровать ненужные фантазии тех же функциональщиков. 3. Выбор программных продуктов для решения сформированного набора задач Ни один программный продукт не позволяет решить все задачи. И даже если мы выбираем красиво укомплектованный маркетологами 1С:ERP, то мы должны быть готовы к тому, что при всей его универсальности мы берем его только как инструмент решения набора ИТ-задач из списка, полученного на 2-м этапе. А для решения полного списка задач мы должны или использовать дополнительные программные продукты, или разрабатывать необходимый функционал внутри 1C:ERP, что может сильно увеличить время и стоимость проекта. Примечание: Здесь, пусть и вскользь, хочется затронуть вопрос: одна база или несколько. Мы со своей стороны не поддерживаем парадигму одной информационной базы. На практике гораздо удобнее в эксплуатации и поддержке система, в которой набор бизнес-задач делится на несколько информационных баз. Разумеется, это мнение субъективно. На этом шаге мы должны проанализировать рынок и определить, в каких существующих программных продуктах какие задачи могут быть решены лучшим образом. Таким образом происходит построение архитектуры ИТ-решений, которые должны появиться в итоге. «Подытог» 1 Мы только что перешагнули экватор и теперь знаем не только «от чего мы уходим» но и «что должно быть результатом» смены платформы ИС. Мы определили: какие информационные базы нам необходимы на каких продуктах они будут созданы какие задачи в каких базах будут решены какой информацией эти базы будут обмениваться между собой Примечание: если текущий ландшафт уже представлен не одной, а несколькими информационными базами, это предполагает, что, скорее всего, заменяться будут не все. Какие-то решения вполне могут остаться в исходном состоянии, если они качественно выполняют возложенные на них функции. Это упрощает процесс перехода и еще раз подчеркивает целесообразность концепции модульности. 4. Разделение задач на набор проектов Практика показывает, что в рамках разработки концепции для среднего/крупного пищевого предприятия у нас появляется от 50 до 100 ИТ-задач, которые должны быть решены. В один присест такое количество задач не решить. Концепция разрабатывается на горизонт 3-4 года. Поэтому мы делим эти задачи на набор проектов. По опыту, для перехода в целевое состояние 100 задач можно скомпоновать в 10-20 проектов. Предполагается, что после каждого проекта система будет находиться в определенном промежуточном устойчивом состоянии. 5. Построение план-графика выполнения проектов по вехам и формирование бюджета проекта По каждому проекту необходимо оценить: ресурсоемкость приоритетность (исходя из потребностей бизнеса) взаимозависимость проектов (некоторые проекты просто невозможно сделать раньше других исходя из технологической зависимости) оценка стоимости привлечения проектных исполнителей «Подытог» 2 Теперь мы знаем не только «какая она, точка В», но и как в нее добраться и сколько времени и денег понадобится на переход. Надо понимать, что адекватные ответы на эти вопросы мы можем получить, только пройдя все шаги именно в вышеуказанной последовательности, а не торопясь с выводами. Прогнозируемые показатели, которые, разумеется, вам никто не запретит делать на любом этапе, так и останутся прогнозами, так как не будут иметь под собой никаких обоснований. Если, к примеру, рассчитать стоимость на втором шаге, не зная, на каких платформах будут реализованы системы, итоговая стоимость будет сильно отличаться от той, на которую вы надеялись. 6. Определение количества необходимых ИТ-ресурсов При невысоком уровне автоматизации предприятию достаточно присутствия системного администратора + максимум одного 1С-ника. Однако, как только компания вступает на путь цифровой трансформации бизнеса и сделаете ИТ-систему важным элементом в эффективности и конкурентной борьбе, перед вами открывается вечно зеленое поле задач по ИТ-поддержке. Автоматизация избавляет вас от необходимости мириться с ошибками неквалифицированных кадров, однако сразу появляется необходимость поддержки системы в целевом состоянии. Поэтому здесь мы определяем структуру и количество необходимых для этого ИТ-ресурсов. Часть этих ресурсов компания обязательно должна иметь внутри, часть можно отдать на аутсорсинг. Подведем ИТОГ В рамках статьи мы рассказали технологию, которой придерживается наша компания. Следуя нашему плану, вы можете разработать концепцию самостоятельно. Однако наше субъективное мнение такое, что разработка концепции – это ремесло, а не 100% стандартизированная работа. И если вы хотите, чтобы новая платформа, как минимум, работала не хуже предыдущей, а желательно и приумножала прибыль, вам просто необходимо участие людей, обладающих опытом разработки подобных концепций. Это позволяет смотреть на ситуацию достаточно широко, чтобы учесть все факторы бизнеса (текущий уровень менеджмента, отношение руководства и персонала к ИТ-технологиям, стадия развития ИТ систем, готовность компании к изменениям). И на основании этого разработать концепцию, максимально полно учитывающую и способную покрыть потребности вашего предприятия.