Краткое содержание:
Чем именно система управленческого учёта отличается от других?
Чего вы ожидаете от внедрения системы, что является целью внедрения?
Какие проблемы могут возникнуть при внедрении системы для управленческого учёта в строительстве?
Система управления бизнесом – «с нуля под себя» или «коробка»?
Руководство компании задумалось о внедрении IT-системы внутреннего управленческого учёта в строительной компании. Если до этого в данной компании не было опыта автоматизации, то возникнут типовые вопросы:
1. Как выбрать АСУ (автоматизированную систему управления) для строительной компании?
2. Как внедрить программу?
3. Какого результата можно ожидать от внедрения программы для строительной компании?
4. Сколько времени и денег на это уйдёт?
5. Кто будет этим заниматься?
6. Как избежать типовых ошибок?
7. Какие сложности могут возникнуть?
Наша компания «АЛТИУС СОФТ» – разработчик программ для управленческого учёта в строительстве – уже проходила эти процессы со многими клиентами и готова поделиться некоторыми наработками – на примере нашей программы для управления строительством.
Чем именно система управленческого учёта отличается от других?
Внедрение информационной системы управления строительным бизнесом (управления проектами, системы внутреннего управленческого учёта) принципиально другое, чем внедрение других типов систем.
Например, если вы внедряете платёжную систему для интернет-магазина, или специфическую систему бухучета, или систему управления складом (для торговой или логистической компании) – то всё гораздо проще. В значительной степени вы можете быть уверены в успешности внедрения и достижения задуманного результата. В какой-то момент отказаться от нового инструмента будет невозможно, поскольку без него бизнес просто остановится. В результате даже при наличии каких-то неудобств система будет работать, а существующие недочеты будут устраняться по мере необходимости силами разработчика и IT-отдела.
С управленческим учётом сложнее: эффект от внедрения наступает не обязательно быстро, заметен не на всех уровнях использования системы управления строительной компанией. Возникают сомнения у пользователей…Ведь до того обходились без программы и при этом компания справлялась, получала прибыль, сотрудники выполняли свои обязанности и т.д.
Именно поэтому довольно часто бывает недостаточно установить систему управления строительством и просто провести обучение специалистов компании, и даже написать для них инструкции. Возможно, потребуются другие действия для достижения результата – уже после приобретения программного обеспечения, его установки и обучения пользователей.
Чего вы ожидаете от внедрения системы, что является целью внедрения?
Если система выбрана с учётом вашей специфики, «подстроена» под вас, обучение пользователей проведено, то когда можно считать, что внедрение прошло успешно?
Чтобы определить, достигнуты ли цели с внедрением системы управления строительством, эти цели необходимо сформулировать. Банально, но факт. Иначе вы не сможете понять, достигнут ли нужный результат от внедрения.
Определите задачи, которые должна решать система; набор данных, который должен храниться и обрабатываться в системе; процессы, которые в одном или нескольких подразделениях должны выполняться и контролироваться в системе; набор отчётности, который будет получать руководство из системы управления строительством.
Но при этом есть обязательная программа-минимум: процессы управления и контроля, которые вы выбрали для автоматизации, регулярно ведутся именно с использованием АСУ.
И только следующие критерии – оптимально выстроенные процессы. А вот как можно понять, что цель достигнута:
• использование программы для строительной компании способствует лучшему планированию деятельности компании и упрощает контроль этих планов, делают его более прозрачным;
• пользователи работают в программе;
• руководство использует информацию из программы для принятия управленческих решений.
Какие проблемы могут возникнуть при внедрении системы для управленческого учёта в строительстве?
Во внедрении системы внутреннего управленческого учёта могут возникнуть сложности, перечислить их все сложно. Расскажем хотя бы о нескольких.
1. Нет опыта внедрения и нет понимания, каких целей можно добиться при внедрении системы управления строительной компании быстро, а какие требуют больше времени и усилий
Если вы столкнулись с задачей внедрения системы управления строительством в первый раз, не стесняйтесь обратиться за помощью к профессионалам.
Уверенность руководителя IT-службы в собственных силах, его умение разбираться в разноплановом ПО, твёрдое убеждение в том, что остальные специалисты компании точно так же – просто, быстро и безболезненно – осваивают новое, владеют навыками самостоятельного изучения ПО, умеют вычленять из инструкций и руководств главную, наиболее актуальную информацию в каждый момент, могут быть ошибочными.
Команда внедрения должна включать руководителя проектов, а зачастую еще и представителей различных подразделений компании, знающих специфику работы своих подразделений, разработчиков – все зависит от задач, которые решает программа для строительной компании, от того, какие подразделения она охватывает.
Вы можете использовать своих имеющихся сотрудников для формирования команды, расширить штат или нанять подрядчика. Однако чаще всего приходится комбинировать различные подходы: в любом случае вам понадобится руководитель проекта и, вероятно, потребуется работать в плотном контакте с разработчиком программного обеспечения.
Как показывает наш опыт при внедрении программы «АЛТИУС – Управление строительством», внедрение систем, затрагивающих работу нескольких отделов, вряд ли будет успешным без руководителя проекта (координатора) именно из числа специалистов компании, в которой внедряется система управления. Специфика работы компании, взаимодействие между разными подразделениями, как правило, хорошо известны «изнутри», и чтобы добиться от сторонних специалистов такого же изучения внутренней кухни «снаружи» – это долгий, дорогой процесс, и всё равно менее успешный, чем с координацией внедрения «изнутри».
2. «Мы думали, эта программа работает по-другому»
Допустим, до внедрения программы для отдела снабжения вы предполагали, что система умеет сама из интернета «вытаскивать» цены на одни и те же материалы у разных поставщиков, сравнивать их, анализировать, но уже после приобретения лицензий и установки АСУ понимаете, что в ней нет такой возможности, а доработка стоит очень дорого.
Не знаем, что посоветовать в таком случае, но можем дать другой простой и надежный совет: изучите АСУ до закупки.
Для этого даже не нужно писать подробное многотомное ТЗ (тем более скорее всего вы не найдёте ни одной готовой системы, которая бы соответствовала заранее вашему ТЗ). Тем не менее, простой список обязательного функционала системы вам нужен. Тогда вы сможете убедиться, насколько программа решает поставленные задачи. Как показывает практика, минимальный (или оптимальный) набор требований может очень сильно отличаться даже для компаний одной и той же отрасли. Есть некоторые общие принципы работы, но в разных компаниях с одним видом деятельности (в нашем примере – в строительстве) бизнес-процессы внутри компаний выстроены по-разному, приоритеты в автоматизации деятельности ставятся разные. Поэтому даже то, что кажется вам «само собой разумеющимся», лучше обсудить с разработчиком и убедиться, что в программе это есть и работает так, как вы себе это представляете.
Перед приобретением программного комплекса «АЛТИУС – Управление строительством» мы проводим потенциальным пользователям индивидуальные презентации бесплатно, разбираем их вопросы и требования к АСУ. А позже при необходимости предоставляем возможность поработать в программе на нашем сервере ещё до приобретения лицензий. Причем, мы проводим не только консультации, но и помогаем разобрать конкретные примеры, сметы (не просто внесение данных), а предлагаем оптимальную механику ведения управленческого учёта, наиболее подходящую конкретным бизнес-процессам строительной компании. Это позволяет избежать «покупки кота в мешке». Вы можете заказать презентацию прямо сейчас, чтобы убедиться в её пользе.
3. Ничего не бывает «раз и навсегда»
Ещё до выбора и внедрения системы нужно понимать, что ваши продуманные требования к ней могут меняться (и скорее всего, будут меняться!). И дело не в том, что вы недостаточно серьёзно отнеслись к составлению требований к системе. А в том, что в жизни, в бизнесе неизбежно происходят изменения, и невозможно предусмотреть всё. Поэтому бороться с возникновением новых требований и пожеланий к ПО, игнорировать их – бесполезно. Нужно отдавать себе отчёт в том, что потребность в доработках может возникнуть, и стараться оптимизировать сроки и бюджет их выполнения.
И ещё есть простой совет: формулируйте, описывайте все новые пожелания к АСУ, но не торопитесь их реализовывать сразу, как только появилась какая-то идея. Причин две.
Во-первых, убедитесь, что эта доработка обязательна для достижения цели внедрения. Бывает, что требование выглядит обоснованным, но существенно не влияет на достижение цели внедрения – значит, такую доработку вполне можно отложить на более поздний срок, когда основная задача внедрения будет достигнута.
Например, если цель внедрения – постановка бюджетирования, то, возможно, некоторые некритичные неудобства при согласовании и визировании документов не помешают добиться автоматизации составления бюджетов по строительным объектам и их актуализации в случае изменения договорных и финансовых условий. А удобство работы в документообороте можно отложить на потом.
И, во-вторых, отсрочка выполнения идей по доработкам имеет смысл, чтобы, возможно, накопить целый пул пожеланий к доработкам и реализовать их позже (последовательно или одновременно). Ведь когда вы рассматриваете пожелания по доработкам комплексно, оценивая весь перечень, проще выявить, какие доработки взаимосвязаны и их логичнее выполнять сразу вместе (так получится быстрее и дешевле), а какие доработки – совершенно отдельные, и могут выполняться в плановом порядке независимо от других.
Если требование пользователя касается интерфейса, удобства работы и не принципиально для выполнения основной задачи, то вполне возможно, что оно вызвано привычкой пользователя, опытом работы с другими программными продуктами. Такие пожелания можно не выполнять немедленно – ведь не исключено, что сотрудники привыкнут к новой программе и через некоторое время перестанут настаивать на изменениях интерфейса. А другие, более важные пожелания могут оказаться нужными многим подразделениям и в целом повысят качество управления компанией.
Но чем больше задач ставится перед системой управления строительством, чем больше подразделений участвует во внедрении, тем вероятнее, что понадобятся доработки, которые будут нужны на самом деле. Если у вас внедрение масштабное, заложите в ваш бюджет внедрения резервную сумму на доработки, предварительно до приобретения АСУ попросив разработчика посчитать стоимость добавления какой-либо важной для вас функции или формы отчётности.
И ещё один из важных критериев: выбирайте гибкую АСУ, отдавайте предпочтение системам, в которых в одних и тех же документах заложена возможность различного заполнения или расчёта, в которых заложенная последовательность бизнес-процессов не жёсткая. Узнайте, возможно ли работать по различным «цепочкам» со связанными документами, пропустить какой-то необязательный этап настроенного процесса. Можно ли внешний вид отчётов перенастроить под требования вашей компании без перепрограммирования. Убедитесь, что стоимость доработок в готовой приобретаемой АСУ гораздо ниже, чем обошлась бы вам разработка АСУ «под себя с нуля».
Кроме того, есть системы, которые в большей степени приспособлены к итерационному внедрению, когда система автоматизации наиболее важных процессов запускается максимально быстро, а функциональность наращивается постепенно.
Что касается нашей системы «АЛТИУС – Управление строительством», она как раз относится к таким программным комплексам, которые можно внедрять постепенно.
Например, если самое больное место – это снабжение строительных объектов и контроль списания материалов, то можно начать с модуля «ОМТС», а в дальнейшем автоматизировать остальные службы.
Или, если в первую очередь необходимо контролировать сроки и физобъёмы работ на объектах и заполнять исполнительную документацию, то можно начать с программы «АЛТИУС – ПТО».
Или, если производственные процессы и снабжение неплохо налажены и без программы, а нужно в первую очередь организовать финансовое планирование, составление бюджетов и контроль затрат, то можно приобрести комплект «Управление строительством Лайт» + модуль «СтройБюджет» и наладить бюджетирование в режиме реального времени, а позже переходить к другим задачам.
И следует учесть, что даже если вам удастся подобрать такую АСУ, что не возникнет необходимости в доработках, то нет гарантий, что такая необходимость не возникнет позже. После внедрения программы компания продолжает развиваться, бизнес-процессы изменяются, АСУ может начать отставать от актуальной структуры вашей компании или от изменения специфики деятельности.
4. Пользователи не хотят работать в АСУ (обычный саботаж)
Мы начинали статью с того, что наладить работу пользователей в системе внутреннего управленческого учёта несколько сложнее, чем во многих других программах.
Основной аргумент: конечные пользователи (а иногда и руководство среднего звена) не видят выгоды для себя от использования программы.
Порой так и есть: не для всех необходимость АСУ очевидна. Для каждого подразделения стоит подобрать заранее доводы в пользу программы: возможно, программа будет составлять за них отчётность, а может быть, сотрудники получат какой-то удобный инструмент, который позволит справляться с работой быстрее и избавить от ошибок, вызванных большим количеством рутинной работы. Если же вы и сами не видите аргументов для работы в программе, то можно постараться упростить необходимую работу в программе, сделать её не очень сложной. Если работа в программе простая и неутомительная, если программа сама отслеживает полноту и правильность внесённых данных, сообщает об ошибках – то пользователям не захочется конфликтовать и тратить силы на споры о нежелании работать в программе.
В то же время нужно стараться развеять иллюзию необязательности работы в АСУ – а для этого существует административный ресурс, и этот способ ещё никто не отменял! Включите в пилотную рабочую группу по внедрению руководителя самого высокого уровня, какого только сможете. От каждого подразделения по возможности подключите к внедрению руководителя, а не рядового сотрудника. В целом по компании, возможно, следует привлечь финансового директора, главного инженера генерального директора или его зама (рекомендации для строительной компании). Пусть они участвуют в совещаниях по внедрению АСУ, а на этапе ввода в эксплуатацию - демонстрируют использование этой же системы для оперативного контроля, для совещаний. И если даже вам не удалось включить руководителей в состав рабочей пилотной группы, – хотя бы убедить их пользоваться отчетами, полученными из программы, это поможет поддержать интерес других специалистов к АСУ.
Если саботаж идёт со стороны лидеров – стоит пригласить их в пилотную группу и уделить внимание их рекомендациям по распределению обязанностей по работе в программе. Иногда достаточно прислушаться к их мнению, и они уже будут на вашей стороне.
5. Программа внедрена, но позднее стала всё меньше использоваться
Чтобы польза от использования управленческой программы не снижалась уже после этапа внедрения, в ходе обычной рабочей эксплуатации программы, нужно не оставлять без внимания и контроля тех сотрудников, которые вводят в АСУ первичные данные. Например, можно оставить какие-то обязанности за тем сотрудником, который в рабочей пилотной группе был координатором. Пусть он задает вопросы специалистам, работающим с программой, рассылая формы обратной связи или регулярно созваниваясь. Желательно, чтобы вопрос формулировался не в виде «все ли у вас в порядке?», но с выяснением деталей и с учётом специфики работы каждого пользователя.
Например:
Наш опыт показывает, что многие пользователи, особенно не уровня управляющего звена, а уровня конечных исполнителей, лишний раз не беспокоят специалистов других подразделений, даже если их работа из-за этого усложняется или выполняется не в полном объёме. Пользователям проще обвинить программу, что «для неё требуется слишком много данных», чем уведомить руководство («накапать»), что другие их коллеги не предоставили необходимую информацию, либо сообщить, что они сами не сделали что-то, требуемое логикой АСУ.
Кроме того, некоторые исполнители (особенно не очень опытные, либо неуверенные в себе, либо опасающиеся потерять работу) часто не обращаются в поддержку, даже если им что-то не сразу понятно.
Например, программа «Исполнительная документация» изначально была простой – она содержала набор заполняемых форм, и её целью было упростить и ускорить для инженера ПТО заполнение исполнительной документации. Со временем, благодаря пожеланиям пользователей, программа стала умнее, добавились механизмы контроля полноты и правильности введённых данных, автоматических проверок и подстановок связанных данных в актах освидетельствования скрытых работ, общем журнале работ, журнале входного учёта и контроля материалов, смете, актах выполненных работ. Но эти возможности далеко не всем нужны (многие просто заполняют формы, как и прежде), для кого-то неочевидны, и иногда даже те ПТОшники, которым в принципе нужны проверки таких взаимосвязей, ими не пользуются. Наши специалисты поддержки периодически обзванивают пользователей, узнают, есть ли вопросы и сложности в работе с программой. Если вопросов накопилось много или требуется обучение новых пользователей, предлагают заключить договор на проведение консультаций по программе (с удалённым подключением к рабочим столам и базе данных пользователей программы) на регулярной основе на какой-то период. За компанией на определённый срок закрепляется специалист техподдержки, и в этот период наш специалист более плотно работает с пользователями, помогает им освоить новые или неочевидные возможности программы, разбирает возникающие сложности.
Чтобы со временем не уменьшался эффект от внедрения АСУ, руководство должно контролировать не только показатели по проектам, договорам, объектам, контрагентам в разных разрезах (сроки, ресурсы, деньги), но и формальную сторону работы в программе: вовремя ли вводятся первичные данные, используется ли на совещаниях отчетность из программы или же используются составленные «на коленке» таблицы и сводки (если это произошло, полезно проанализировать, какие процессы изменились и следует ли внести эти изменения в АСУ в виде доработок) и так далее.
Система управления бизнесом – «с нуля под себя» или «коробка»?
Проекты внедрения АСУ для внутреннего управленческого учёта (как и любых других систем) можно крупно и условно разделить на два вида.
1. Классический проект внедрения программного обеспечения
Это стандартные этапы: обследование, написание ТЗ, настройка/разработка, тестирование, обучение, опытная эксплуатация.
Внедрение по этой схеме проходит всегда последовательно, оно занимает длительное время и довольно затратно по деньгам. Значительная доля затрат приходится не на собственно внедрение, а на «бумажные» этапы: обследование, написание ТЗ, составление списка изменений в процессе опытной эксплуатации, написание инструкций. Внутри этапов часто какие-то работы выполняются параллельно, однако общий порядок этапов изменить нельзя: нельзя приступить к написанию ТЗ без обследования, невозможно составить список изменений без опытной эксплуатации и т.д.
Такие проекты иногда просто неизбежны: уникальность бизнес-процессов компании, отсутствие на рынке готовых решений, которые подходят хотя бы на 50%, и т.д.
Но в тех случаях, когда это возможно, мы предлагаем другой подход.
2. Итерационное внедрение готовых программных продуктов
Вся задача по автоматизации компании разбивается на функциональные подзадачи, например:
• Договоры и сметы с заказчиками, закрытие работ и взаиморасчёты с заказчиками
• Материально-техническое снабжение
• Бюджетирование и контроль затрат
• Исполнительная документация
• Субподрядчики (все функции аналогично блоку работы с заказчиками)
• Документооборот
• и так далее
Если это возможно, какие-то модули внедряются по очереди (если невозможно – то часть модулей и функций запускается параллельно), и внутри каждого выполняется такая последовательность работ:
Эти этапы применимы для многих готовых систем, поскольку здесь не нужны обследование, написание ТЗ, тестирование – предполагается начинать сразу с обучения пользователей. А в ходе опытной эксплуатации выявляется необходимость внесения изменений в программу (доработок).
Функционал АСУ большей частью вводится в работу последовательно, а результатом каждого мини-этапа является рабочая эксплуатация системы, при необходимости – с доработками функционала.
И что немаловажно, если во внедрении такой системы требуются какие-то доработки (изменение бизнес-логики документов, сложные индивидуальные отчеты, расширение системы сообщений), то это целесообразно отложить до более поздних этапов, уже после внедрения выбранных типовых модулей.
Такой подход ближе тем компаниям, которые ориентированы на быстрый результат и готовы принять некоторый типовой функционал готовой программы, освоить работу в незнакомом интерфейсе: если программа в целом решает поставленные задачи, то быстро «прогнать» тестовый пример в АСУ в режиме опытной эксплуатации (по одному или нескольким тестовым объектам). И при отсутствии принципиальных препятствий сразу начать использовать эту программу в работе по всем объектам, а доработки удобства и вспомогательных сервисов, в случае необходимости, отложить на потом. В этом случае можно внедрить небольшой, но самодостаточный модуль системы – в течение месяца или даже недели.
Например, в программе «Исполнительная документация» можно начать работать за один день.
В программе «АЛТИУС - ПТО» – полноценно в течение нескольких дней.
В модулях «ОМТС» или «Поставщики и закупки» – в течение одной-двух недель.
А полный комплекс «АЛТИУС – Управление строительством» (при отсутствии сложных доработок, существенно меняющих логику ввода документа, расчётов) – в течение от одного до трёх месяцев.
Система внутреннего управленческого учёта – не то же самое, что бухгалтерия, склад или система биллинга. Это объективно более сложная система и требует большего внимания при внедрении. Для внедрения требуется участие представителей разных подразделений, руководства, а также нужен координатор «изнутри».
Вы можете внедрять систему сами или с подрядчиком, писать программу «под себя с нуля» или используя коробочное решение, но в любом случае от руководства потребуется участие во внедрении, а от пользователей – время и усилия по изучению программы.
Желаем вам успешных проектов по внедрению АСУ для автоматизации вашей работы!
А за программами для управления строительством вы всегда можете обратиться к нам.
Вся информация на сайте носит справочный характер и не является публичной офертой, определяемой положениями Статьи 437 Гражданского кодекса Российской Федерации. Технические параметры (спецификация), комплект поставки товара, лицензий, состава услуг могут быть изменены производителем без предварительного уведомления.
Во избежание недоразумений для получения точной информации о стоимости и наличии представленного на сайте товара, услуг, лицензий, пожалуйста, дополнительно узнавайте по телефону или электронной почте.