Статья посвящена реальному проекту, который мы делали для одной организации. Что было сделано плохо, что хорошо, судить вам. Одной из особенностей и сложности проекта было то, что нужно было спасать всё и сразу.
Итак, пищевое производственное предприятие с одним удаленным филиалом. Общие штат компании около 700 человек. Центр - производство вин, шампанского, на филиале производство сидра, водки, настройки. Центр и филиал в разных городах.
Исходное состояние:
Железо: пара самосборных серверов и «зверинец» из рабочих станций, в том числе исполняющих различные серверные роли: интернет, принт-сервер, контроллер домена основной и резервный и прочее. Филиал был подключен через программный VPN-клиент для Windows ZyXEL ZyWALL VPNClient.
Штат: 1 админ, 1 программист в штате, 1 программист приходящий, 1 техник на обслуживание рабочих мест: заправка картриджей, мелкий ремонт и тому подобное.
Софт 1С: ЗУП (там ничего интересного не было, работала себе и работала J). Центральная база – «допиленная» 1С:Бухгалтерия, файловая на платформе 1С:7.7, размер около 10 Гб… и это DBF... В базе работало порядка 200 пользователей, из них постоянных с 9-00 до 18-00 не менее 80 (бухгалтерия, отдел продаж, выписка, маркетинг) . Производство реализовано было укрупненно – разносили пропорционально сырье и затраты на готовую продукцию не по SKU, а на тип/группу продукции, До нормальной полной автоматизации производства при мне в этой компании так и не дошли, были только перспективные планы, но, насколько знаю, и по сей день остались исключительно в виде перспективных планов.
В рабочее время при пиковых нагрузках на базу, последняя успешно «падала», а после естественно требовала переиндексацию. Таким образом,первые 2 недели каждого месяца, когда идет закрытие бухгалтерского периода, база ежедневно вываливалась по 2-4 раза в день и общий простой иногда составлял до 3 часов РАБОЧЕГО времени. Компания несла колоссальные затраты, т.к. во время простоя заказы не попадают в базу, не формируются маршруты и рейсы, не отгружается продукция, наемный транспорт простаивает у ворот склада, а полки в магазинах успешно занимают конкуренты.
Регулярные падения базы время от времени приводили к появлению битых таблиц в базе, терялись или сбивались движения документов, в результате до и после переиндексаций на одни и те же даты получались разные остатки товара, сальдо по взаиморасчетам, значение себестоимости продукции.
Особенностью ведения учета в компании на тот момент было полное отсутствие управленческого учета, все строилось на бухгалтерских данных, расчет остатков, сальдо и все отчеты строились по плану счетов, даже резервирование товаров происходило через забалансовые счета. И это при документооброте 1 000 документов в день.
Например, закрытие взаиморасчетов делалось один раз в день после разнесения банковской выписки одним огромным документом, который проводился по 30-40 минут , причем в это время всем остальным пользователям было запрещено работать в программе, формировать тяжелые отчеты, был, так называемый, «час тишины». В противном случае файловая база падала от нагрузки.
Дело было в конце 2009 года и на тот момент было абсолютно понятно, что рано или поздно, но от платформы 1С:7.7 придется отказываться в пользу 8-ки. Понятно для специалистов 1С, но требует некоторой аргументации для собственника. Одних заявлений о моральном устаревании текущей системы не достаточно.
Но также предельно ясно, что быстрых и волшебных вариантов нет. Для перехода на новую систему для предприятия такого уровня по предварительным оценкам потребуется (от старта до запуска в опытную эксплуатацию) не менее 12-ти месяцев с проектной группой в 5-6 человек. И всё это время компания должна осуществлять свою деятельность, т.е. с одной стороны необходимо поддерживать старую систему, сражаться с бесконечными проблемами и параллельно внедрять новую.
При принятии решения о переходе на новую учетную систему я рекомендую составить таблицу, чтобы визуализировать проблемы, расставить приоритеты и приступить к планированию мероприятий.
В первую очередь нужно ответить на вопросы:
1. Зачем вообще нужно что-то изменять? Определяем слабые места информационной системы и формулируем необходимость изменений.
2. Что поможет решить текущие проблемы? Перечисляем возможные варианты.
Варианты решений оцениваем в трех измерениях: сроки, человеческие ресурсы, стоимость.
План разделили на два принципиальных блока: стабилизация текущей системы и сам проект.
1. HardWare
1.1. Перенос баз на профессиональное серверного оборудование HP и системы хранения данных EVA, параллельно велись проекты по переходу с Kerio на MSExchange и шлюза Gateway на Linux.
2. SoftWare
2.1. Перевод файловой базы на SQL;
Переход на SQL нам должен был дать бесперебойность, релевантность данных, но, как побочный эффект – уменьшение быстродействия, о чем бизнес, конечно же, мы предупредили заранее. Известные нам узкие места мы определили и провели некоторую оптимизацию кода, но понятно, что переписывать под SQL конфигурацию полностью смысла не было, нам всего лишь нужно было выиграть некоторое время спокойной работы, для выбора и адаптации нового решения.
2.2. Виртуализация (VMware), как средство повышения отказоустойчивости и гибкого управления производительностью;
2.3. Критичные по быстродействию рабочие места переводим под RDP
3. Организационные
3.1. Кадровые изменения в ИТ (замена программиста, увольнение того, кому перемен и вообще думать на работе о работе не хотелось, нашли специалиста 1С:7.7, готового к развитию и переменам).
3.2. Вводим в компании обязательный почасовой регламент работы пользователей с основной базой
Этап стабилизации системы:
1. Переход на SQL.Разворачиваем копию, режем данные прошлых периодов, бэкапим средствами 1С, разворачиваем на SQL. Тестируем, производим замеры быстродействия (они насконечно же не радуют), проверяем остатки, работу критичной отчетности. После чего запускаем на боевой базе.
По срокам все было рассчитано так, что отрезали прошлый год и перешли на новуюSQL-базу в январе.
Главная цель достигнута - база работает стабильно, целостность и доступность данных обеспечена, но производительность все же значительно просела. «Злые языки» жаловались руководству и просили нас заставить вернуть все, «как было». Но с директором нам повезло, он из бывших айтишников (конечно же, если допустить, что в нашей специальности можно быть «бывшим», навыки, логика, системное мышление остаются J) поэтому никакие варианты возврата к старой схеме работы не рассматривались.
2. Оптимизация работы со старой базой 1C:7.7
2.1. Разрабатываем систему отчетности для быстрого обнаружения и исправления ошибок в базе после сбоев;
2.2. Оптимизация узких мест для увеличения быстродействия;
2.3. Создание периферийных баз для формирования отчетности;
2.4. Формирование специфичной отчетности ботами по ночам и выкладывание Excel-файлов на сетевых ресурсах;
2.5. Организуем хранилище данных OLAP по отгрузкам и взаиморасчетам (ночные выгрузки).
Результат комплекса мероприятий – система стабилизирована, можно приступать к проекту!
Проект: план перехода из старой системы в новую
По проекту сталкиваемся с суровой реальностью: хороших специалистов на рынке не много, расширять штат в 3 раза под проект собственник однозначно не готов, да и на поиск, адаптацию персонала нужно не менее 3-х месяцев, что однозначно повлияет на сроки проекта, значит нужно смотреть в сторону поиска внешних разработчиков. Идеальным выглядит сотрудничество с местным франчайзи, у которого мы могли бы приобрести готовое решение, максимально близкое потребностям бизнеса, и воспользоваться их обученными специалистами на нашем проекте.
Франчайзи предлагает свое решение и специалистов-внедренцев, хорошо им владеющим, все логично? J
Мы предложили руководству компромиссный, поэтапный переход на новую систему, где первым этапом запускаем наиболее критичные для бизнеса модули.
По проекту составляем подробное описание взаимодействия новой и старой системы по каждому из этапов.
Контрагенты
Сопоставление объектов по взаиморасчетам
Движения 7.7 -> 8.2
Выписка банка: Создается в 7.7. в 8.2 переносится как ВводНачальныхОстатковВзаиморасчеты
БухСправка: касательно движений только по 62 счету
Создается в 7.7. в 8.2 переносится как ВводНачальныхОстатковВзаиморасчеты
Анализировать на наличие 62 счета как по дебету, так и по кредиту
НедостачаОтгруженного(старый возврат от покупателя в 77)
Если происходит возврат товаров отгруженных до запуска отгрузок в 8.2 - то переносим
взаиморасчеты (62 счет) как ВводНачальныхОстатковВзаиморасчеты
===================================
Движения 8.2 -> 7.7
РасходнаяНакладная:
Вводятся в 8.2 переносятся в 7.7. в ПереносРасходных
ПриходнаяНакладная (новый возврат от покупателя)
Создается в 8.2, если отгрузка была в 8.2, переносится в 7.7. как ПереносРасходных с «минусом»
ЗакрытиеВзаиморасчетов:
Создается в 8.2 в 7.7. переносится в БухСправку
Второе субконто подбирается бух справкой в 7.7 на основании ссылки на расходную или номера/даты расходной
Номенклатура и партии
В процессе реализации проекта вприобретенной конфигурация обнаруживаем сюрпризы:
- Разрабатывалась явно разными программистами и в разное время, например, функции получения продажной цены и расчета себестоимости для заказов, реализации находятся не в общих модулях и получаются централизовано по одному алгоритму, а расположены в модулях самих документов, причем написаны по разному и явно разными разработчиками;
- Ни один документ не умеет проводиться на сервере, весь функционал разработан только под клиента;
- Доработки от внешних специалистов приходят с опозданием и не работающим функционалом, под каждый чих с нас просят оформление акта выявленных ошибок, в том числе даже когда реализация явно кардинально отличается от ТЗ;
- Подписание актов выполненных работ затягивается на недельные дебаты;
- Не используются управляемые блокировки, система начала тормозить практически на первой неделе опытной эксплуатации;
Суровая реальность на проекте
Работа с заказчиками:
Все документировалось и до запуска презентовалось бизнесу, в буквальном смысле. Создавались презентации в PowerPoint или MS Visio и на картинках каждый шаг укрупненно демонстрировался и согласовывался. Из своего опыта могу сказать, что такое ведение проектов достаточно эффективно, даже если в компании существуют четкие регламенты по документообороту, «много букв» и умных фраз зачастую проигрывают «картинкам». Длинные тексты никто не читает.
Сопротивление внутренний клиентов:
Что делает большинство пользователей на больших проектах? Не знаю, как у других, у меня они как правило отчаянно сопротивляются "разумному. доброму, вечному" и очень не любят перемен, как выход из привычной зоны комфорта. Зачем "рисковать" и изучать что-то новое, когда так комфортно ныть и жаловаться, как все плохо. Этот проект не оказался исключением и пользователи "пели" стандартные "песни":
- "не ломайте то, что есть», «не мешайте работать»
- «оставьте 1С:7.7 и старую базу, только сделайте её быстрой»
- «нет времени обучаться, много работы», «не понимаем, как и что нужно делать»(это уже саботаж)
Предпринятые шаги:
- Пошаговые инструкции
- Тестовые задания под подпись (персональное обучение)
- Прогон цепочек бизнес-процессов с участием сотрудников нескольких подразделений на тестовой базе (групповое обучение)
- Полноценный компьютерный класс для обучения
- Уступки по интерфейсу обработок (кнопки в привычных местах), плюс пиар новых возможностей самой платформы
- Логирование действий пользователей в старой и новой базе (срезаем на корню заявления «я этого не делала»)
- Поддержка топ-менеджмента, административный ресурс(был издан Приказ директора о лишении премий, за отказ работы в новой системе)
Ошибки, сделанные на проекте:
1. Плохо изучили конфигурацию до её приобретения. Ожидали типовую с белорусской локализацией, получили ужасную самописку;
2. Договор на внедрение не содержал обязательств по гарантированному выделению ресурсов и соблюдению сроков проекта. По факту внешний подрядчик оказался не в состоянии предоставить специалистов необходимого уровня квалификации и в нужном нам объеме человеко/часов ;
Положительные моменты на проекте:
- Заручение поддержкой топ-менеджмента компании;
- Привлечение квалифицированных специалистов под 100% загрузку на проекте, вплоть до хантинга кадров у франча. J Формирование команды единомышленников;
- Правильная стратегия стабилизации работы в старой системе и поэтапного перехода на новую отдельными модулями;
- Обучение пользователей персональное и групповое, причем под подпись;
Проект завершен был успешно с незначительным превышением сроков и бюджета!
***********************
Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.
