Какие проблемы могут возникнуть при внедрении системы для управленческого учета в строительстве

Во внедрении системы внутреннего управленческого учета могут возникнуть сложности, перечислить их все сложно. Расскажем хотя бы о нескольких. В качестве примера приведем программы «АЛТИУС» — комплекс российских IT-решений от компании «АЛТИУС СОФТ».

1. Нет опыта внедрения и нет понимания, каких целей можно добиться при внедрении системы управления строительной компании быстро, а какие требуют больше времени и усилий

Если вы столкнулись с задачей внедрения системы управления строительством в первый раз, не стесняйтесь обратиться за помощью к профессионалам.

Уверенность руководителя IT-службы в собственных силах, его умение разбираться в разноплановом ПО, твердое убеждение в том, что остальные специалисты компании точно так же — просто, быстро и безболезненно — осваивают новое, владеют навыками самостоятельного изучения ПО, умеют вычленять из инструкций и руководств главную, наиболее актуальную информацию в каждый момент, могут быть ошибочными.

Команда внедрения должна включать руководителя проектов, а зачастую еще и представителей различных подразделений компании, знающих специфику работы своих подразделений, разработчиков — все зависит от задач, которые решает программа для строительной компании, от того, какие подразделения она охватывает.

Вы можете использовать своих имеющихся сотрудников для формирования команды, расширить штат или нанять подрядчика. Однако чаще всего приходится комбинировать различные подходы: в любом случае вам понадобится руководитель проекта и, вероятно, потребуется работать в плотном контакте с разработчиком программного обеспечения.

Как показывает наш опыт при внедрении программы «АЛТИУС — Управление строительством», внедрение систем, затрагивающих работу нескольких отделов, вряд ли будет успешным без руководителя проекта (координатора) именно из числа специалистов компании, в которой внедряется система управления.

Специфика работы компании, взаимодействие между разными подразделениями, как правило, хорошо известны «изнутри», и чтобы добиться от сторонних специалистов такого же изучения внутренней кухни «снаружи» — это долгий, дорогой процесс, и все равно менее успешный, чем с координацией внедрения «изнутри».

2. «Мы думали, эта программа работает по-другому»

Допустим, до внедрения программы для отдела снабжения вы предполагали, что система умеет сама из интернета «вытаскивать» цены на одни и те же материалы у разных поставщиков, сравнивать их, анализировать, но уже после приобретения лицензий и установки АСУ понимаете, что в ней нет такой возможности, а доработка стоит очень дорого.

Не знаем, что посоветовать в таком случае, но можем дать другой простой и надежный совет: изучите АСУ до закупки.

Для этого даже не нужно писать подробное многотомное ТЗ (тем более скорее всего вы не найдете ни одной готовой системы, которая бы соответствовала заранее вашему ТЗ). Тем не менее, простой список обязательного функционала системы вам нужен. Тогда вы сможете убедиться, насколько программа решает поставленные задачи.

Как показывает практика, минимальный (или оптимальный) набор требований может очень сильно отличаться даже для компаний одной и той же отрасли. Есть некоторые общие принципы работы, но в разных компаниях с одним видом деятельности (в нашем примере — в строительстве) бизнес-процессы внутри компаний выстроены по-разному, приоритеты в автоматизации деятельности ставятся разные. Поэтому даже то, что кажется вам «само собой разумеющимся», лучше обсудить с разработчиком и убедиться, что в программе это есть и работает так, как вы себе это представляете.

Перед приобретением программного комплекса «АЛТИУС — Управление строительством» мы проводим потенциальным пользователям индивидуальные презентации бесплатно, разбираем их вопросы и требования к АСУ. А позже при необходимости предоставляем возможность поработать в программе на нашем сервере еще до приобретения лицензий.

Причем, мы проводим не только консультации, но и помогаем разобрать конкретные примеры, сметы (не просто внесение данных), а предлагаем оптимальную механику ведения управленческого учета, наиболее подходящую конкретным бизнес-процессам строительной компании. Это позволяет избежать «покупки кота в мешке». Вы можете заказать презентацию прямо сейчас, чтобы убедиться в ее пользе.

Программы для строительной организации: «АЛТИУС»

Все решения готовы к внедрению в строительных компаниях различной численности и профиля: от ИП до крупных холдингов

3. Ничего не бывает «раз и навсегда»

Еще до выбора и внедрения системы нужно понимать, что ваши продуманные требования к ней могут меняться (и скорее всего, будут меняться!). И дело не в том, что вы недостаточно серьезно отнеслись к составлению требований к системе. А в том, что в жизни, в бизнесе неизбежно происходят изменения, и невозможно предусмотреть все. Поэтому бороться с возникновением новых требований и пожеланий к ПО, игнорировать их — бесполезно. Нужно отдавать себе отчет в том, что потребность в доработках может возникнуть, и стараться оптимизировать сроки и бюджет их выполнения.

И еще есть простой совет: формулируйте, описывайте все новые пожелания к АСУ, но не торопитесь их реализовывать сразу, как только появилась какая-то идея. Причин две.

Во-первых, убедитесь, что эта доработка обязательна для достижения цели внедрения. Бывает, что требование выглядит обоснованным, но существенно не влияет на достижение цели внедрения — значит, такую доработку вполне можно отложить на более поздний срок, когда основная задача внедрения будет достигнута.

Например, если цель внедрения — постановка бюджетирования, то, возможно, некоторые некритичные неудобства при согласовании и визировании документов не помешают добиться автоматизации составления бюджетов по строительным объектам и их актуализации в случае изменения договорных и финансовых условий. А удобство работы в документообороте можно отложить на потом.

И, во-вторых, отсрочка выполнения идей по доработкам имеет смысл, чтобы, возможно, накопить целый пул пожеланий к доработкам и реализовать их позже (последовательно или одновременно). Ведь когда вы рассматриваете пожелания по доработкам комплексно, оценивая весь перечень, проще выявить, какие доработки взаимосвязаны и их логичнее выполнять сразу вместе (так получится быстрее и дешевле), а какие доработки — совершенно отдельные, и могут выполняться в плановом порядке независимо от других.

Если требование пользователя касается интерфейса, удобства работы и не принципиально для выполнения основной задачи, то вполне возможно, что оно вызвано привычкой пользователя, опытом работы с другими программными продуктами. Такие пожелания можно не выполнять немедленно — ведь не исключено, что сотрудники привыкнут к новой программе и через некоторое время перестанут настаивать на изменениях интерфейса. А другие, более важные пожелания могут оказаться нужными многим подразделениям и в целом повысят качество управления компанией.

Но чем больше задач ставится перед системой управления строительством, чем больше подразделений участвует во внедрении, тем вероятнее, что понадобятся доработки, которые будут нужны на самом деле.

Если у вас внедрение масштабное, заложите в ваш бюджет внедрения резервную сумму на доработки, предварительно до приобретения АСУ попросив разработчика посчитать стоимость добавления какой-либо важной для вас функции или формы отчетности.

И еще один из важных критериев: выбирайте гибкую АСУ, отдавайте предпочтение системам, в которых в одних и тех же документах заложена возможность различного заполнения или расчета, в которых заложенная последовательность бизнес-процессов не жесткая. Узнайте, возможно ли работать по различным «цепочкам» со связанными документами, пропустить какой-то необязательный этап настроенного процесса. Можно ли внешний вид отчетов перенастроить под требования вашей компании без перепрограммирования. Убедитесь, что стоимость доработок в готовой приобретаемой АСУ гораздо ниже, чем обошлась бы вам разработка АСУ «под себя с нуля».

Кроме того, есть системы, которые в большей степени приспособлены к итерационному внедрению, когда система автоматизации наиболее важных процессов запускается максимально быстро, а функциональность наращивается постепенно.

Что касается нашей системы «АЛТИУС — Управление строительством», она как раз относится к таким программным комплексам, которые можно внедрять постепенно.

Например, если самое больное место — это снабжение строительных объектов и контроль списания материалов, то можно начать с модуля «ОМТС», а в дальнейшем автоматизировать остальные службы.

Или, если в первую очередь необходимо контролировать сроки и физобъемы работ на объектах и заполнять исполнительную документацию, то можно начать с программы «АЛТИУС — ПТО».

Или, если производственные процессы и снабжение неплохо налажены и без программы, а нужно в первую очередь организовать финансовое планирование, составление бюджетов и контроль затрат, то можно приобрести комплект «Управление строительством Лайт» + модуль «СтройБюджет» и наладить бюджетирование в режиме реального времени, а позже переходить к другим задачам.

И следует учесть, что даже если вам удастся подобрать такую АСУ, что не возникнет необходимости в доработках, то нет гарантий, что такая необходимость не возникнет позже. После внедрения программы компания продолжает развиваться, бизнес-процессы изменяются, АСУ может начать отставать от актуальной структуры вашей компании или от изменения специфики деятельности.

4. Пользователи не хотят работать в АСУ (обычный саботаж)

Мы начинали статью с того, что наладить работу пользователей в системе внутреннего управленческого учета несколько сложнее, чем во многих других программах.

Основной аргумент: конечные пользователи (а иногда и руководство среднего звена) не видят выгоды для себя от использования программы.

Порой так и есть: не для всех необходимость АСУ очевидна. Для каждого подразделения стоит подобрать заранее доводы в пользу программы: возможно, программа будет составлять за них отчетность, а может быть, сотрудники получат какой-то удобный инструмент, который позволит справляться с работой быстрее и избавить от ошибок, вызванных большим количеством рутинной работы.

Если же вы и сами не видите аргументов для работы в программе, то можно постараться упростить необходимую работу в программе, сделать ее не очень сложной. Если работа в программе простая и неутомительная, если программа сама отслеживает полноту и правильность внесенных данных, сообщает об ошибках — то пользователям не захочется конфликтовать и тратить силы на споры о нежелании работать в программе.

В то же время нужно стараться развеять иллюзию необязательности работы в АСУ — а для этого существует административный ресурс, и этот способ еще никто не отменял!

Включите в пилотную рабочую группу по внедрению руководителя самого высокого уровня, какого только сможете. От каждого подразделения по возможности подключите к внедрению руководителя, а не рядового сотрудника.

В целом по компании, возможно, следует привлечь финансового директора, главного инженера генерального директора или его зама (рекомендации для строительной компании). Пусть они участвуют в совещаниях по внедрению АСУ, а на этапе ввода в эксплуатацию — демонстрируют использование этой же системы для оперативного контроля, для совещаний. И если даже вам не удалось включить руководителей в состав рабочей пилотной группы, — хотя бы убедить их пользоваться отчетами, полученными из программы, это поможет поддержать интерес других специалистов к АСУ.

Если саботаж идет со стороны лидеров — стоит пригласить их в пилотную группу и уделить внимание их рекомендациям по распределению обязанностей по работе в программе. Иногда достаточно прислушаться к их мнению, и они уже будут на вашей стороне.

5. Программа внедрена, но позднее стала все меньше использоваться

Чтобы польза от использования управленческой программы не снижалась уже после этапа внедрения, в ходе обычной рабочей эксплуатации программы, нужно не оставлять без внимания и контроля тех сотрудников, которые вводят в АСУ первичные данные. Например, можно оставить какие-то обязанности за тем сотрудником, который в рабочей пилотной группе был координатором.

Пусть он задает вопросы специалистам, работающим с программой, рассылая формы обратной связи или регулярно созваниваясь. Желательно, чтобы вопрос формулировался не в виде «все ли у вас в порядке?», но с выяснением деталей и с учетом специфики работы каждого пользователя.

Например:

«есть ли вопросы по загрузке смет по новому объекту?»;
«получили ли вы график производства работ и ввели его в программу?»;
«все ли понятно с внутренними нормативами (сдельными расценками, ценами на материалы, стоимостью аренды машин и механизмов) по новому объекту, или же для расчета плановой себестоимости вам не предоставлены какие-то исходные данные?».

Наш опыт показывает, что многие пользователи, особенно не уровня управляющего звена, а уровня конечных исполнителей, лишний раз не беспокоят специалистов других подразделений, даже если их работа из-за этого усложняется или выполняется не в полном объеме. Пользователям проще обвинить программу, что «для нее требуется слишком много данных», чем уведомить руководство («накапать»), что другие их коллеги не предоставили необходимую информацию, либо сообщить, что они сами не сделали что-то, требуемое логикой АСУ.

Кроме того, некоторые исполнители (особенно не очень опытные, либо неуверенные в себе, либо опасающиеся потерять работу) часто не обращаются в поддержку, даже если им что-то не сразу понятно.

Например, программа «Исполнительная документация» изначально была простой — она содержала набор заполняемых форм, и ее целью было упростить и ускорить для инженера ПТО заполнение исполнительной документации. Со временем, благодаря пожеланиям пользователей, программа стала умнее, добавились механизмы контроля полноты и правильности введенных данных, автоматических проверок и подстановок связанных данных в актах освидетельствования скрытых работ, общем журнале работ, журнале входного учета и контроля материалов, смете, актах выполненных работ. Но эти возможности далеко не всем нужны (многие просто заполняют формы, как и прежде), для кого-то неочевидны, и иногда даже те ПТОшники, которым в принципе нужны проверки таких взаимосвязей, ими не пользуются.

Наши специалисты поддержки периодически обзванивают пользователей, узнают, есть ли вопросы и сложности в работе с программой. Если вопросов накопилось много или требуется обучение новых пользователей, предлагают заключить договор на проведение консультаций по программе (с удаленным подключением к рабочим столам и базе данных пользователей программы) на регулярной основе на какой-то период.

За компанией на определенный срок закрепляется специалист техподдержки, и в этот период наш специалист более плотно работает с пользователями, помогает им освоить новые или неочевидные возможности программы, разбирает возникающие сложности.

Чтобы со временем не уменьшался эффект от внедрения АСУ, руководство должно контролировать не только показатели по проектам, договорам, объектам, контрагентам в разных разрезах (сроки, ресурсы, деньги), но и формальную сторону работы в программе: вовремя ли вводятся первичные данные, используется ли на совещаниях отчетность из программы или же используются составленные «на коленке» таблицы и сводки (если это произошло, полезно проанализировать, какие процессы изменились и следует ли внести эти изменения в АСУ в виде доработок) и так далее.

Ответим на ваши вопросы и проведем бесплатную персональную презентацию. Заказать.