Бурный рост заставил руководство ФПК "Сатори" по-новому взглянуть на проблемы информационного обеспечения ключевых бизнес-процессов.
Бурный рост известной на московском строительном рынке компании заставил ее руководство по-новому взглянуть на проблемы обработки данных и информационного обеспечения сотрудников. В ходе проекта по автоматизации компания усовершенствовала учетную политику и приступила к ИТ-поддержке проектной деятельности.
«Традиционно на ИТ-службу нашей строительной фирмы возлагались, во-первых, задачи обеспечения связи, и, во-вторых, автоматизации», — рассказывает Владимир Окунцов, начальник отдела ИТ «Финансово-промышленной корпорации ?Сатори?». Исторически строительные организации развивались так, что размер головного офиса был невелик; сотрудники в основном трудились на строительных объектах. Вопросы связи и оперативного взаимодействия менеджеров офиса с прорабами и начальниками участков всегда имели первостепенное значение: от того, насколько быстро поступала информация с объекта, зависела ритмичность всего цикла строительных работ на объекте, в том числе своевременность поставки стройматериалов, закрытие работ на объектах и пр.
Однако долгое время основой обмена данными между удаленными площадками служили средства связи, а не информационная система в ее классическом понимании. Почти вся обработка данных, за исключением бухгалтерского учета, велась вручную. Пока потоки данных были относительно невелики, в компании с этим мирились.
После кризиса 1998 года на столичном строительном рынке произошло укрупнение бизнеса: компании, более благополучно пережившие кризис, стали поглощать менее успешных соседей и конкурентов. Предприниматели поняли: чем крупнее организация, тем больше у нее возможностей для получения выгодных и престижных заказов. Такая компания может вести бизнес более экономично и распределять ресурсы между объектами с минимальным числом простоев и авралов.
Еще одна характерная черта первых лет после кризиса — строительный бум в столице. Так, по данным правительства города, объем строительства в 1999 году составил около 40,6 млрд. руб., тогда как годом раньше — 28,5 млрд. руб. Инвесторы стали активно вкладывать свои деньги в недвижимость, не особенно доверяя ценным бумагам. Требовали замены основные фонды ряда московских предприятий. Кроме того, на рынок столичного региона стали выходить зарубежные игроки. Создание новых объектов и реконструкция обветшавших зданий значительно увеличили потоки заказов строительных организаций. Одновременно с этим усилилась конкуренция на заказы между компаниями, сумевшими пережить кризис.
Рост бизнеса и укрупнение в конце 90-х коснулись и компании «Сатори». Так, в течение 1999 года объемы заказов на снос строений выросли на 15%, объемы работ общестроительного участка — на 47%, землеройного — на 30%. Многократно выросли объемы заказов на снос строений, общестроительные и землеройные работы. Все это привело не только к увеличению информационных потоков, но также к появлению новых направлений деятельности (генподряд, инвестиционная деятельность) и к переосмыслению основ учетной политики. В частности, повысились требования к прозрачности и управляемости компании, усилен контроль рентабельности выполнения работ на объектах, как следствие — возникла необходимость в более оперативном сборе и обработке информации, необходимой для управления предприятием.
Следует пояснить, что в процессе строительства объектов очень часто приходится переоценивать стоимость работ на том или ином объекте. Причина — скрытые работы. Например, при строительстве в городе котлована могут встретиться старые коммуникации, не указанные в строительных сметах, или остатки старых московских домов, мостовых и пр., которые важно сохранить для археологов. Строительные организации стараются отслеживать хронологию изменения бюджета объекта, чтобы не допустить ситуации, когда в результате появления скрытых работ объект станет убыточным.
Инвестиции в будущее
В 2000 году руководство компании поставило вопрос о широкой автоматизации процессов обмена данными и их обработки. Со стороны предприятия это были инвестиции в бизнес. «Прибыльность строительной организации и система мотивации рабочих в значительной степени зависит от своевременности получения информации и ее корректности», — поясняет Окунцов.
К тому времени из средств автоматизации в компании имелась только бухгалтерская программа «Паруса» в DOS-версии, развернутая менее чем на десяти рабочих местах. Склады вели свою деятельность разрозненно. Документы со складов предоставлялись с задержкой в один-два месяца. Полная информация о поступлении материалов, их списании, о дебиторской и кредиторской задолженности была недоступна ключевым менеджерам.
Это и послужило непосредственным импульсом к автоматизации. Кроме того, производившаяся вручную подготовка важных транспортных документов (путевые листы, наряд-заказы) существенно тормозила работу автотранспортного подразделения и автотехцентра.
Инициатива осуществления масштабной автоматизации нашла активную поддержку среди высших руководителей предприятия. Наиболее горячими ее сторонниками выступили директор по экономике и финансам, директор по организационному развитию и начальник службы ИТ. Новая информационная система должна была поддержать не только текущие процессы, но и дальнейшее развитие компании.
К началу 2000 года служба ИТ разработала концепцию автоматизации предприятия. В марте того же года ее утвердили. Суть концепции сводилась к автоматизации двух контуров: оперативно-финансового (он включал все подразделения и службы, участвовавшие в подготовке и обработке информации финансово-экономического характера) и производственного (он охватывал службы, предоставляющие производственную информацию, а также отдел кадров). С этого момента началась планомерная автоматизация.
Поскольку весь кадровый документооборот в отделе труда и заработной платы был бумажным, в службе ИТ пошли по пути «латания дыр». Для начала развернули систему «1С:Зарплата и кадры». Это было необходимо, чтобы в короткие сроки систематизировать кадровый документооборот. В строительном бизнесе он является одним из ключевых, поскольку на него оказывают существенное влияние сезонность работ, высокая текучесть и колебания численности персонала, а также многочисленность применяемых схем расчета зарплаты. На внедрение системы ушло примерно полгода.
|
| Владимир Окунцов, начальник отдела ИТ «Финансово-промышленной корпорации ?Сатори?» |
Одновременно с этим начались поиски подходящей интегрированной информационной системы. К тому времени ИТ-специалисты компании изучили около десятка различных систем, начиная от SAP R/3 и заканчивая «1С:Предприятием».
К концу 2000 года в «Сатори» пришли к заключению о том, что готового комплексного решения для автоматизации предприятия строительного бизнеса на рынке не найти.
«Специфика нашего бизнеса состоит в ориентации на проекты. Отсюда — потребность в автоматизации ведения проектов и их бюджетов. Традиционные модули информационных систем (бухгалтерский, складской и пр.) могут помочь поддержать лишь обеспечивающие процессы», — говорит Окунцов.
Было решено ограничить дальнейший выбор спектром систем от надежных поставщиков, основанных на клиент-серверной архитектуре и использующих в качестве СУБД платформу Oracle. Таким образом предполагалось обеспечить необходимый уровень надежности, быстродействия и масштабируемости системы. Этот выбор был обусловлен, во-первых, бурным ростом предприятия, и, во-вторых, наличием нескольких территориально распределенных офисов.
Еще один важный критерий — минимизация морально-психологических потрясений для сотрудников. В бухгалтерии уже применялись программные продукты «Парус» и у его пользователей сложилась определенная методология совместной работы с системой, поэтому руководство «Сатори» остановилось на «Парусе».
Первые опыты
Прежде всего предприятие приобрело несколько лицензий системы и в течение достаточно продолжительного времени тестировало ее, чтобы удостовериться в надежности и устойчивости системы. Изучались многие ее аспекты, начиная от «дружественности» интерфейса и сложности выполнения типовых бухгалтерских и складских операций, и заканчивая реакцией системы на различные программно-аппаратные сбои. ИТ-специалисты остались довольны результатами длившегося несколько месяцев эксперимента.
За тестированием наступило время экспресс-обследования, в ходе которого представители компании совместно со специалистами «Паруса» проанализировали должностные инструкции сотрудников и изменили некоторые из них таким образом, чтобы адаптировать их деятельность к ролевым функциям, предусмотренным в рамках методологии, заложенной в восьмую версию «Паруса».
В конце 2001 года началась непосредственная подготовка к переходу на новую систему. В частности, потребовалось значительно изменить справочники номенклатуры используемых на предприятии строительных материалов, техники и комплектующих к ней. «К сожалению, мы недооценили трудоемкость перехода и уделили недостаточно внимания преобразованию справочников, разработке и согласованию их многоуровневой иерархии. Мы серьезно занялись ими лишь после того, как перенесли информацию из старой версии в новую», — сожалеет Окунцов.
Также усложнили развертывание системы переход с начала 2002 года на новый план счетов, вызванный изменениями в законодательстве, и новая политика предприятия, касающаяся учета основных средств. Если прежде к основным средствам относили активы, стоимость которых превышала 100 МРОТ, то с 2002 года — все товарно-материальные ценности, которые могли эксплуатироваться больше года. На переход к новой политике учета основных средств потребовалось достаточно много времени.
Изменения в налоговом законодательстве потребовали ведения налогового учета отдельно от бухгалтерского.
«Многие предприятия пошли по пути параллельного учета бухгалтерской и налоговой информации в двух разных базах данных, — говорит Окунцов. — Использование системы «Парус» позволило совместить оба вида учета в одной базе данных: для подготовки регистра налогового учета мы использовали данные бухучета».
Адаптация к бизнесу
Опытная эксплуатация системы началась летом 2002 года. К этому моменту она была развернута в бухгалтерии и на складах, информация оперативно поступала со складов в бухгалтерию — данные об изменениях на складах стали передаваться за один-два дня (скорость передачи данных ограничивалась оперативностью обработки документов сотрудниками складов).
«К этому времени система претерпела определенные изменения: было разработано около 100 процедур, которые не меняли радикально функций, но помогали адаптировать ее к особенностям бизнес-процессов нашего предприятия», — рассказывает Окунцов.
В частности, были написаны процедуры для подготовки расходных накладных на списание материалов. В силу специфики бизнеса предприятия значительная часть материалов отправляется на объекты, минуя склады (такую логистическую цепочку обычно называют «поступление транзитом»). В отличие от классической схемы, которая предусматривает приемку материалов на основе приходных накладных, затем списание их на объектах по расходным накладным, в данном случае происходит оперативное списание материалов прямо на объектах. Разработанные процедуры в несколько раз ускорили процесс приемки/списания материалов. Обработку приходных и подготовку расходных накладных в системе осуществляют сотрудники склада.
Еще одна важная группа процедур обеспечила поддержку материальных отчетов прорабов (в конце каждого месяца они должны формировать отчеты о списании ТМЦ по завершении работ, произведенных за месяц). Стандартные средства «Паруса» предполагают списание материалов по объектам на основе данных бухгалтерского учета с применением усредненных закупочных цен. Разработанные для «Сатори» процедуры были призваны поддержать учетную политику, которой придерживается большинство строительных предприятий: она предусматривает списание материалов на объектах по фактическим ценам.
Поскольку к опытной эксплуатации привлекались наиболее подготовленные и заинтересованные в автоматизации сотрудники подразделений, проект развертывания системы не встретил сколько-нибудь заметного сопротивления со стороны персонала.
Следующие шаги
Летом 2002 года на предприятии началось изучение вопроса о развитии системы. Поскольку компания располагает большим парком автотранспорта, было решено автоматизировать подготовку путевых листов и заодно оптимизировать транспортные потоки (раньше планирование автотранспорта и подготовка путевых листов велась вручную). Это позволило готовить документы для водителей заблаговременно, внося последние данные в них непосредственно перед выездом.
Попавшие в общую базу данных сведения из путевых листов (в частности, информация о пробеге автомобилей) применяются для определения работ по техобслуживанию автотранспорта. Эти процедуры позволяют увеличить время продуктивной эксплуатации транспорта. Ранее, чтобы спланировать техобслуживание, приходилось вручную анализировать путевые листы, а затем консолидировать информацию о пробеге каждого автомобиля. В процессе ремонта автомобилей по мере выявления скрытых дефектов и планирования работ, связанных с их устранением, нередко случалось по несколько раз их переписывать. В настоящее время операции по подготовке наряд-заказов производятся автоматически, а трудоемкость внесения в них изменений минимизирована.
Автоматизация обеспечила контроль расходования ТМЦ, используемых для технического обслуживания и ремонта транспорта, что также принесло предприятию определенную экономию средств. До того, как этот участок работ был автоматизирован, для проведения ремонтно-профилактических работ нередко приходилось производить дополнительные закупки деталей и материалов, которые на самом деле имелись на складах. Как правило, это было связано с нестыковкой номенклатурных справочников (одна и та же запчасть могла называться по-разному в справочниках технических и складских служб). В результате автоматизации удалось не только сократить объемы закупок запчастей и материалов для ремонта техники, но и устранить простои при ремонте благодаря тому, что закупка этих запчастей и материалов планировалась заранее.
Автоматизация проектного бизнеса
Для строительной организации большое значение имеет автоматизация ведения бюджета объекта. В ходе выполнения работ может возникнуть необходимость внесения изменений в план и смету проекта, вызванных появлением скрытых работ, изменением расценок на материалы и пр. При составлении бюджета объекта кроме анализа себестоимости работ, оценки средств, выделяемых на оплату труда, рассчитывается прибыльность отдельных участков работ. Предприятию важно оперативно отслеживать информацию, касающуюся бюджета проекта.
От маржинального дохода объекта нередко зависит оплата рабочих, которые на нем трудятся. До недавнего времени расчет фонда оплаты труда осуществлялся по мере закрытия работ. В случае если информация с объекта поступает не вовремя, то зарплата рабочим начисляется не совсем корректно, в результате чего могут возникнуть существенные отклонения от данных о зарплате, предусмотренных сметой объекта. Кроме того, задержка информации искажает данные о себестоимости объекта, что может привести к принятию неверных управленческих решений. Автоматизация ведения бюджета объекта, предусматривающая совмещение в одной базе данных сведений и о плановых, и о фактических показателях, позволит решить перечисленные проблемы строительного предприятия.
В ходе анализа бизнес-процессов удалось выделить единый технологический процесс обеспечения строительной деятельности. В компании он отнесен к разряду основных. В рамках этого процесса постоянно решается целый ряд задач, требующих автоматизации:
- разработка сметы на проведение работ;
- составление бюджета объекта на основе сметы;
- подготовка плана-графика выполнения работ на объекте (основой для этого служит его бюджет);
- закрытие позиций бюджета на основе актов выполненных работ;
- закрытие бюджета объекта в целом и расчет себестоимости объекта.
В настоящее время модуль, реализующий эти функции, находится в стадии опытной эксплуатации. В дальнейшем планируется осуществить интеграцию этого модуля со стандартными пакетами проектирования строительных объектов (САПР) и составления смет. По всей вероятности, эти пакеты будут включены в комплексную информационную систему управления строительной деятельностью. Таким образом предполагается обеспечить ИТ-поддержку всего цикла работ, начиная с проектирования объекта и заканчивая вводом его в эксплуатацию.
«Очень важно, чтобы вся ИТ-поддержка строительных работ велась с применением единой базы данных», — говорит Окунцов.
Кроме того, предприятие намерено провести автоматизацию финансового планирования и контроля исполнения финансовых планов, управления дебиторско-кредиторской задолженностью, процедур план-фактного анализа бюджетов объектов и предприятия в целом, анализа причин отклонения от бюджетов и пр. Для повышения точности анализа планируется осуществить интеграцию строительного решения с системой класса OLAP и корпоративным порталом.
Инфраструктура
В настоящее время в компании применяется около 150 компьютеров (три года назад их было втрое меньше). На 60 из них развернута система «Парус». Ею пользуются сотрудники бухгалтерии, складов, планово-экономического, финансового, сметно-договорного, технического отделов, отделов производственно-технологической комплектации, материально-технического снабжения, труда и заработной платы, автоколонны, автотехцентра и столовой. Система интегрирована с восемью приложениями класса «клиент-банк». Развитие системы осуществляется силами двух программистов при поддержке консультантов «Паруса».
«Сатори»
ООО «Финансово-промышленная корпорация ?Сатори?» специализируется на комплексной подготовке строительных площадок, включая снос строений, вывоз и переработку строительного мусора, земляные работы, прокладку инженерных коммуникаций. Кроме того, компания выполняет общестроительные работы, в частности генподрядные, монолитные работы, благоустройство территорий, ремонт и техническое обслуживание строительной техники и грузового автотранспорта, транспортные услуги и пр.
В компании работает около 1000 человек, в том числе более 150 сотрудников офисов и менеджеров.
Человеческий фактор
В ходе внедрения и развития системы возникало немало курьезных ситуаций, вызванных психологическими трудностями привыкания к новой технологии. Условно их можно разбить на три группы.
Во-первых, на начальном этапе у части сотрудников бухгалтерии, ранее работавших в версии «Паруса» для DOS, возникали трудности с использованием манипулятора «мышь». Как выяснилось в беседах с внедренцами системы в других организациях, им иногда приходилось специально настраивать интерфейс, чтобы минимизировать работу с «мышью» и, соответственно, «ностальгию» по привычной системе.
Во-вторых, неумение у части пользователей четко формулировать требования к настройке системы вызывало у них периодически желание перейти на такую систему автоматизации, где эти требования так или иначе реализованы. При этом назывались самые различные системы, начиная от достаточно современных и дорогих типа Axapta и заканчивая привычной для небольших предприятий системой «1С:Предприятие 7.7». После выяснения того, что хочет тот или иной пользователь, эти проблемы, как правило, снимались.
В-третьих, имели место и такие ситуации, когда стремление быстро решить ту или и иную задачу путем «заплатки» приводило к неоправданным организационным сложностям. Так, например, было с автоматизацией ведения путевых листов, когда один из сотрудников решил эту задачу с помощью СУБД Access, не согласовав с единой базой данных. Это на несколько дней парализовало работу диспетчерской автоколонны, пока задача не была решена с использованием СУБД Oracle.
Все эти ситуации являются достаточно типичными и могут иметь место при решении вопросов внедрения различных систем автоматизации.
Анализ опыта
- Следует уделять больше внимания предпроектному обследованию и подготовке проекта внедрения системы. Необходимо четко спланировать порядок автоматизации отдельных участков предприятия.
- Не нужно жалеть времени на анализ бизнес-процессов не только на этапе предпроектного обследования, но и в дальнейшем. Это дает возможность более точно сформулировать требования к техническому заданию и своевременно изменить должностные инструкции пользователей, чтобы подготовить их к переходу на новую систему и осуществить адаптацию системы к бизнес-процессам предприятия.
- Любой переход на новую систему должен предусматривать удобный перенос справочников. Этот перенос нередко проходит болезненно.