Переход на новую учетную систему: что предусмотреть бухгалтеру

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

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

1. Определите цель и составьте план действий

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

Например, вы решили приобрести систему «1С:Бухгалтерия». Если вы спросите у своего бухгалтера о цели покупки, он ответит: решение необходимо, чтобы вести учёт, вводить документы, формировать проводки. Однако это не цель всего проекта. После наводящего вопроса «А зачем всё это?» — сотрудник ответит: «Чтобы сдать отчётность и распечатать накладную». Но и это не цель, а лишь функционал, инструмент, который помогает достичь цели. В конечном счете, мы придем к выводу, что без отчетности компанию ждут штрафы, санкции и репутационные риски, которые приведут к потере клиентов. А отсутствие автоматизации снизит эффективность бизнес-процессов.

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

Будьте готовы к личному участию и ответственности за принятие решений. Часто заказчики представляют весь процесс покупки решения в виде «купил, установил и работаю». В случае с программами управления и учёта это легко может привести к фатальной недооценке бюджета. Приготовьтесь к большому объёму работ, требующих финансирования. Почти всегда они существенно дороже самой системы.

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

2. Выберите программный продукт

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

Будьте внимательны: часто поставщик предлагает готовое решение, не задумываясь, а нужно ли оно поставщику. Например, строительной организации часто сразу предлагают модуль «Управление строительной организацией» на базе УПП. Впоследствии функционал УСО часто не востребован у заказчика, а деньги уже потрачены. Ничто не мешало купить УПП, а позже проапгрейдит" его до УСО при необходимости. Ещё хуже, когда ненужную готовую разработку продают под видом дорогостоящих работ. Не спешите покупать кота в мешке, изучите, что вы покупаете.

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

Далее нужно выбрать между простыми и более сложными конфигурациями. Здесь надо оценивать конкретную ситуацию. Простые конфигурации, как правило, не требуют мощных ресурсов. Также это надёжное разграничение доступа: пользователь одной базы не получит доступ к данным другой, т.к. он в ней просто не работает. Единая конфигурация предполагает более развитый функционал и меньшее количество лицензий (те, кто работали в двух базах, работают в одной). Но главное — нет проблем с лишними обменами данных. Это всегда слабое место, трудоёмкое в доработке.

Любая доработка готовой системы — дорогое удовольствие. Для дополнительных возможностей есть много готовых решений, которые можно найти на «Инфостарте», сайте «1С:Совместимо», сайтах-партнёров 1С, но их покупка требует более тщательных проверок, и надо обязательно советоваться со специалистом, который будет их внедрять.

Часто встаёт вопрос: процесс в типовом решении построен не так, как надо. Его надо дорабатывать. Но не спешите. Все операции из типовых решений опробованы тысячами пользователей — и работают!

Чтобы принять верное решение, оцените стоимость решения и доработок, а также выгоды от автоматизации.

3. Выберите поставщика

Чем меньше ваш проект, и чем меньше требований, тем будет проще искать поставщика. Небольшие объёмы работ по настройке можно выполнить самостоятельно. Чем сложнее проект и жёстче бюджет, тем выше риск самых больших материальных потерь вследствие провала проекта.

Проверьте наличие у потенциального исполнителя необходимых ресурсов: запросите данные именно тех специалистов, которые будут работать с вами, а не «среднюю температуру по больнице». Особое внимание уделите руководителю проекта со стороны интегратора. Это очень частый рекламный ход — на встречу приезжает один из лучших специалистов, но на ваш проект он не попадёт.

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

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

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

У наработок есть обратная сторона медали. Некоторые работают по одному шаблону, и не готовы идти навстречу вашим требованиям. Конечно, любой поставщик может предложить не то, что вы планировали купить. Обязательно рассмотрите и обсудите полученные предложения. Они могут быть настолько выгоднее, что пересматривается весь проект. А может быть, поставщик не понял задачи, при обсуждении вы увидите это.

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

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

Любой поставщик, к которому вы обратитесь, сразу же предложит обследование текущих бизнес-процессов. Вы не знаете возможностей продукта (если знаете — это снизит объём экспертизы, но не отменит её), а исполнитель работ — особенностей вашего бизнеса. Срок выполнения обследования — от одного дня до месяца. Основная задача — выявить необходимые для начала эксплуатации работы. Остальное — кто бы и как вас ни убеждал — опционально. Дело в том, что никакая экспертиза не охватит всех ваших пожеланий и деталей бизнеса. Изменения будут. Но они будут более осознанными, полными и правильно реализованными при наличии опыта работы в программе у ваших пользователей. Частая уловка — бесплатная экспертиза или большая скидка на неё. Цель уловки — «ввязаться в бой». Расчёт на то, что, потратив время и деньги, вы не дадите уже обратный ход, попадёте в зависимость от исполнителя.

Вот, что должны содержать результаты исследования:

• информацию, необходимую для понимания документа третьими лицами. В нём могут быть словарь, описание структуры подразделений, краткое описание и назначение взаимодействующих программ, описание оборудования заказчика, и т.д;
• обоснованный выбор программного продукта;
• два варианта изменений серверного и сетевого оборудования: минимальный и рекомендуемый (по мнению исполнителя) или заключение о пригодности оборудования;
• список необходимых работ и поставок;
• список требований сторон;
• оценку времени работников заказчика, которое потребуется уделить проекту;
• план-график с указанием стоимости по каждому пункту работ и поставок;
• предварительная оценка каждого этапа по срокам и суммам;
• список некритических, но планируемых или рекомендованных исполнителем работ и поставок;
• список наборов прав (ролей) пользователей, которые будут работать в системе.

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

Рекомендую в договоре указать обязанность исполнителя доработать документ по замечаниям заказчика и представить его в окончательном виде до первого этапа. Это позволит обойти ряд проблем:

• нечитаемый документ. Часто то, что исполнитель называет «профессиональным языком», на деле оказывается простой безграмотностью. Уважающий свою работу аккуратный исполнитель никогда не передаст чистовой вариант, изобилующий ошибками;
• отсутствие результата. Грамотно составленные документы могут оказаться неподходящими: договор для другой организации бегло исправили под ваши задачи. Мне встречались случаи, когда даже название организации забывали исправить;
• информация, не соответствующая действительности.

4. Заключайте договор

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

Перечислю только некоторые из частых ошибок:

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

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

5. Начинаем работать в системе

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

Каждая программа имеет настройки, и их немало. Так же, как и с установкой, рекомендую ввод настроек своими силами под контролем и с консультациями исполнителя. Для этого потребуется, чтобы настройки были распределены между ответственными лицами.

После начала работы появляются вопросы по существу, массовый сбор идей и возможность спланировать внедрение с учётом особенностей программы. Часто исполнитель сначала дорабатывает программу, а потом пускает туда пользователей. Это неправильно! Начинайте работать сразу же, как появится возможность, и есть высокая вероятность того, что доработки не потребуются и будет сэкономлено много денег.

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

6. Проведите необходимые доработки

Доработки на данном этапе выполняются только необходимые. Устраняются препятствия, которые критически мешают кому-то работать. Например, не разграничены права доступа. Если можно работать без доработки — она откладывается. Все, у кого помех нет — работают, формируют свои пожелания, из которых составляется план развития системы.

Частая ошибка — разработка функционала, который уже есть в типовой конфигурации. Она возникает из-за:

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

Запомните: любая, а особенно — некачественно сделанная доработка повышает стоимость обслуживания системы.

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

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

ТЗ не должно содержать:

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

В случае простых или однозначно понимаемых доработок составление технического задания превратится в лишние трудозатраты.

Михаил Персианов, ведущий специалист отдела 1С BDO Unicon Outsourcing

ИА Клерк.ру