Доработка программного обеспечения: как отразить в бухгалтерском учете и в целях налогообложения
Через три года использования ПО со сроком полезного использования 5 лет организацией были выполнены доработки ПО (например расширение функционала ПО). Доработку, оформляемую актом выполненных работ (оказанных услуг), производит организация, предоставившая неисключительные права на использование программного продукта. Согласно учетной политике организации расходы на доработку будут также равномерно списываться. Возможно ли установить в договоре на доработку ПО срок полезного использования больше срока полезного использования основного ПО?
Каковы сроки отражения в бухгалтерском учете и признания в целях обложения налогом на прибыль расходов на произведенную сторонней компанией доработку программного обеспечения?
По данному вопросу мы придерживаемся следующей позиции:
При доработке ПО организация вправе установить срок полезного использования, соответствующий лицензионному договору на доработку, в том числе если он превышает срок полезного использования основного ПО, либо самостоятельно установить срок, равный оставшемуся сроку полезного использования основного ПО, или, если организация предполагает использовать доработанное ПО свыше оставшегося срока, установить срок, превышающий оставшийся срок полезного использования основного ПО, и признавать в бухгалтерском и налоговом учете расходы на доработку ПО равномерно в течение установленного ею срока.
При этом, учитывая позицию финансового ведомства, целесообразнее установить срок использования доработки программного продукта в пределах оставшегося срока полезного использования самого программного продукта.
Бухгалтерский учет
В соответствии с пп. 1 п. 1 ст. 1236 ГК РФ лицензионный договор может предусматривать предоставление лицензиату права использования результата интеллектуальной деятельности с сохранением за лицензиаром права выдачи лицензий другим лицам (простая (неисключительная) лицензия).
Абзацем вторым п. 4 ст. 1235 ГК РФ определено, что в случае, когда в лицензионном договоре срок его действия не определен, договор считается заключенным на пять лет.
Бухгалтерский учет расходов регламентируется положениями ПБУ 10/99 «Расходы организации».
Пунктом 2 ПБУ 10/99 определено, что расходами организации признается уменьшение экономических выгод в результате выбытия активов (денежных средств, иного имущества) и (или) возникновения обязательств, приводящее к уменьшению капитала этой организации.
Расходы по обычным видам деятельности принимаются к бухгалтерскому учету в сумме, исчисленной в денежном выражении, равной величине оплаты в денежной и иной форме или величине кредиторской задолженности. Если оплата покрывает лишь часть признаваемых расходов, то расходы, принимаемые к бухгалтерскому учету, определяются как сумма оплаты и кредиторской задолженности (в части, не покрытой оплатой) в соответствии с п. 6 ПБУ 10/99.
Расходы на доработку программного обеспечения подлежат учету в составе прочих расходов по обычным видам деятельности (п. 8 ПБУ 10/99).
Расходы согласно п. 16 ПБУ 10/99 признаются в бухгалтерском учете при наличии следующих условий:
— расход производится в соответствии с конкретным договором, требованием законодательных и нормативных актов, обычаями делового оборота;
— сумма расхода может быть определена;
— имеется уверенность в том, что в результате конкретной операции произойдет уменьшение экономических выгод организации, то есть в случае, когда организация передала актив либо отсутствует неопределенность в отношении передачи актива.
Пунктом 18 ПБУ 10/99 определено, что расходы признаются в том отчетном периоде, в котором они имели место, независимо от времени фактической выплаты денежных средств и иной формы осуществления (допущение временной определенности фактов хозяйственной деятельности).
Пунктом 65 Положения по ведению бухгалтерского учета и бухгалтерской отчетности в РФ, утвержденного приказом Минфина России от 29.07.1998 N 34н, установлено, что затраты, произведенные организацией в отчетном периоде, но относящиеся к следующим отчетным периодам, отражаются в бухгалтерском балансе в соответствии с условиями признания активов, установленными нормативными правовыми актами по бухгалтерскому учету, и подлежат списанию в порядке, определенном для списания стоимости активов данного вида.
«Планом счетов бухгалтерского учета финансово-хозяйственной деятельности организаций и инструкции по его применению», утвержденным Приказом Минфина России от 31.10.2000 N 94н, для обобщения информации о расходах, произведенных в данном отчетном периоде, но относящихся к будущим отчетным периодам, предназначен счет 97, перечень которых является открытым.
Исходя из вышесказанного, организация может признавать указанные затраты равномерно в течение установленного периода использования, закрепив метод учета в учетной политике (п. 4 ПБУ 1/2008). Причем привязки к оставшемуся сроку использования ПО законодательство по бухгалтерскому учету не содержит.
По нашему мнению, при доработке ПО организация вправе установить срок полезного использования, соответствующий лицензионному договору на доработку, в том числе, если он превышает срок полезного использования основного ПО, либо, например, в случае, когда в договоре не предусмотрен данный срок, самостоятельно установить срок, равный оставшемуся сроку полезного использования основного ПО, или, если организация предполагает использовать доработанное ПО свыше оставшегося срока, установить срок, превышающий оставшийся срок полезного использования основного ПО, и признавать расходы на доработку ПО в течение установленного ею срока.
Следует отметить, что организация должна правомерно использовать программный продукт, иначе расходы, связанные с его доработкой, обновлениями, обслуживанием, и прочие не могут быть приняты к учету.
Налоговый учет
Расходы, связанные с приобретением права на использование программ для ЭВМ, а также на приобретение исключительных прав на программы для ЭВМ стоимостью менее суммы стоимости амортизируемого имущества, определенной п. 1 ст. 256 НК РФ (40 000 рублей) на основании пп. 26 п. 1 ст. 264 НК РФ относятся к прочим расходам, связанным с производством и реализацией налогоплательщика.
Ранее этот пункт содержал норму о возможности включения в состав расходов затраты на обновление программ для ЭВМ (норма отменена с 01.01.2012). В период ее действия финансовое ведомство в своих письмах признавало согласно пп. 26 п. 1 ст. 264 НК РФ возможность учета расходов на усовершенствование (доработку) программы единовременно (пп. 3 п. 7 ст. 272 НК РФ) вне зависимости от величины данных затрат (письма Минфина России от 31.10.2011 N 03-03-06/1/704, от 29.09.2011 N 03-03-06/1/601).
Так как пп. 26 п. 1 ст. 264 НК РФ в настоящее время не содержит упоминания о подобного рода издержках, их можно учесть согласно пп. 49 п. 1 ст. 264 НК РФ в качестве других расходов, связанных с производством и (или) реализацией.
Абзацем первым п. 1 ст. 272 НК РФ установлено, что при применении метода начисления расходы для целей налогообложения признаются в том отчетном (налоговом) периоде, к которому они относятся, независимо от времени фактической выплаты денежных средств и (или) иной формы их оплаты и определяются с учетом положений ст.ст. 318-320 НК РФ.
Расходы подлежат признанию в том отчетном (налоговом) периоде, в котором возникают исходя из условий сделок. Если сделка не содержит таких условий и связь между доходами и расходами не может быть определена четко или определяется косвенным путем, расходы распределяются налогоплательщиком самостоятельно (абзац второй п. 1 ст. 272 НК РФ).
Существуют судебные решения, в которых правомерным признается единовременное признание налогоплательщиками таких затрат в целях исчисления налога на прибыль (постановление ФАС Западно-Сибирского округа от 15.03.2013 N Ф04-933/13 по делу N А27-11302/2012, постановления ФАС Поволжского округа от 12.07.2012 N Ф06-5251/12, Северо-Западного округа от 21.07.2011 N Ф07-12326/10 по делу N А56-48512/2009, постановления Четвертого арбитражного апелляционного суда от 03.04.2014 N 04АП-4378/13, Седьмого арбитражного апелляционного суда от 08.07.2013 N 07АП-4496/13, от 28.11.2012 N 07АП-9152/12 и другие).
Таким образом, можно в налоговом учете предусмотреть единовременное отнесение в расходы затрат на доработку программного обеспечения, но, учитывая наличие арбитражной практики, организации нужно быть готовой отстаивать свою точку зрения в суде.
Вопрос по близкой к описанной Вами ситуации, где обновления ПО, купленного по договорам с правообладателями, в том числе лицензионным, сублицензионным (неисключительные имущественные права на использование программного обеспечения для ЭВМ), приобретались на основании отдельных договоров с правообладателями, в том числе лицензионных, сублицензионных, рассмотрен в письме Минфина России от 13.02.2012 N 03-03-06/2/19. Финансовое ведомство разъясняет, что если из условий договора на приобретение неисключительных прав нельзя определить срок использования программ для ЭВМ, то затраты на приобретение ПО распределяются с учетом принципа равномерности признания доходов и расходов. При этом налогоплательщик в налоговом учете вправе самостоятельно определить период, в течение которого указанные расходы подлежат учету для целей налогообложения прибыли. Порядок признания в целях налогообложения прибыли в отношении расходов по работам, связанным с обновлением и модификацией ПО, результаты которых будут использоваться налогоплательщиком в течение срока использования программного продукта, аналогичен порядку учета самого ПО (смотрите также письма Минфина России от 18.03.2013 N 03-03-06/1/8161, от 19.07.2012 N 03-03-06/1/346, от 23.10.2009 N 03-03-06/1/681, от 18.04.2007 N 03-03-06/2/75).
При доработке ПО организации целесообразнее установить срок полезного использования, соответствующий договору на доработку, либо самостоятельно установить срок, равный оставшемуся сроку полезного использования основного ПО. В случае если организация установит срок использования доработки, превышающий срок применения ПО, нужно быть готовым к возможным претензиям со стороны контролирующих органов.
Ответ подготовил:
Эксперт службы Правового консалтинга ГАРАНТ
Карасёва Анна
Контроль качества ответа:
Рецензент службы Правового консалтинга ГАРАНТ
профессиональный бухгалтер Мягкова Светлана
Материал подготовлен на основе индивидуальной письменной консультации, оказанной в рамках услуги Правовой консалтинг.
Модернизация программного обеспечения — зачем нужна и как заказать
Любой программный продукт, предназначенный для работы под той или иной платформой, имеет свой срок службы, зависящий от стремления и возможностей компании-разработчика по поддержке своего решения в процессе его эксплуатации заказчиками. Как только разработчик отказывается поддерживать выпущенный продукт, у использующих его компаний или потребителей возникает потребность модернизации программного обеспечения, чтобы оно соответствовало возросшим запросам или изменившейся конъюнктуре применения. О том, зачем это нужно и каким образом можно заказать модификацию программы или мобильного приложения, постараемся рассказать в рамках текущего материала.
Причины
Первое, с чего стоит начать, это причины возникновения потребности в модернизации программного обеспечения, а говоря простым языком — его модификации под нужды пользователя. Возникнуть они могут, исходя из многих факторов, основные из которых перечислим ниже:
Процесс устаревания ПО провоцирует существенное снижение эффективности программного обеспечения, модернизацию которого обычно выполняет разработавшая продукт компания. Но зачастую последним приходится отказываться от поддержки устаревшего продукта в пользу разработки более совершенного ПО. Стоимость более современной программы может оказаться существенно выше уже выплаченной покупателем в момент приобретения эксплуатируемого ПО суммы, что зачастую становится крайне невыгодным мероприятием.
Однако чаще всего потребность модернизировать программу или целый комплекс возникает по причине расширения спектра задач, которые должно охватывать ПО. В том числе за счет увеличения количества сотрудников, с ним взаимодействующих, либо банальной необходимости улучшить и расширить пользовательский интерфейс.
Задачи модернизации ПО
Процедура модернизации программного обеспечения преследует сразу несколько целей, полностью перекрывающих потребности организаций, заинтересованных в заказе такого рода услуг. Перечислим их:
Компания, выполняющая работы по модификации программного обеспечения, получает от заказчика полный список задач, которые требуется выполнить в рамках предстоящей модернизации. Только Гграмотно составленное техническое задание на проведение предстоящих работ обеспечит полное соответствие модернизированного ПО требованиям клиента, о чем задумавшимся об улучшении используемых на предприятии программ руководителям стоит побеспокоиться заранее. Также необходимо заключить с разработчиком, готовым произвести модернизацию ПО, специальный договор, описывающий условия и сроки дальнейшей технической поддержки улучшившего функционал решения.
Где заказать?
Выбор разработчика, осуществляющего модификацию “чужих” программ или мобильных приложений, основывается на специфике применения нуждающегося в изменении ПО. Самым оптимальным будет разослать запросы компаниям-разработчикам с подробным перечнем требований к обновленному функционалу эксплуатируемого продукта, чтобы те смогли оценить свои возможности и подготовить для заказчика свой список уточняющих вопросов либо направить встречное предложение о проведении работ по модификации ПО. Вопрос стоимости модернизации программного обеспечения напрямую зависит от сроков реализации задуманного, а также квалификации команды разработчиков, которой предстоит выполнять работы. Все пункты предстоящего взаимодействия сторонам соглашения стоит обсудить заранее, включая этапы и форму проведения тестирования промежуточных версий модифицированной под нужды заказчика программы. Это застрахует обе стороны от возникновения спорных вопросов, особенно в части финансового обеспечения работ.
Внедрение программного продукта. Особенности работы бизнес-консультанта. Часть II
Не в количестве знаний заключается образование, а в полном понимании и искусном применении всего того, что знаешь.
Говорить о внедрении программного продукта можно очень долго, тема это обширная, а нюансов в работе бизнес-консультанта очень много. В первой части Внедрение программного продукта. Особенности работы бизнес-консультанта. Часть I я раскрыл только некоторые общие понятия, пояснил, чем работа бизнес-консультанта для малого и среднего бизнеса отличается от работы обычных внедренцев. Также я рассказал о тех базовых принципах, на которых я строю свою работу по внедрению программного обеспечения.
Итак, о постановке цели мы говорили много и в этой, и в предыдущих статьях. Думаю, здесь вопросов возникнуть не должно. Но на всякий случай напомню: речь идет о бизнес-цели, под которую мы и выбираем программное обеспечение.
Ввод остатков в программу
Ввод остатков в программу – это первый этап непосредственно вашей работы по внедрению программного продукта. И этот этап призван решить широкий перечень задач:
1.Наглядность. Клиент сразу увидит, каким образом его данные будут отображаться в программе. Сможет уточнить свои пожелания и потребности. Подсказать какие-то решения, удобные для его бизнеса и его сотрудников.
2.Изучение нюансов работы. В процессе переноса остатков вы сможете выяснить очень много нюансов работы компании, разобраться, как работает какой из отделов, какие данные им нужны для работы, какие документы и отчеты чаще всего используются. Также вы на практике изучаете работу самого программного продукта (если не были знакомы с ним прежде). На основе этих данных вы сможете написать техническое задание для программиста.
Обратите внимание! Я программистам техническое задание пишу, это удобно для всех. Сам же я не настаиваю на наличии ТЗ или брифов. Об этом я уже говорил здесь.
Уточняется необходимость в доработках. Этот пункт становится итогом предыдущих. С одной стороны, вы понимаете, требуются ли программные доработки, и если они нужны, то какие именно. С другой – ваш клиент также видит свои остатки в программе, может представить, как она будет работать, и внести дополнительные пожелания по доработкам.
Например: Клиент в своей программе хранит специфическую информацию о своих покупателях. При переносе обнаруживается, что в новой программе нет подходящего справочника, т.е. эту информацию некуда переносить. Кроме того, работа с любой информацией не ограничивается хранением, необходимо как-то использовать эту информацию в новой программе. Значит, нужно разобраться, для чего эта информация была нужна, где она применялась, и соответствующим образом доработать новый программный продукт.
Итак, техническое задание составлено. Вы передаете работу программисту, получаете результат, и можете переходить к обучению сотрудников компании. (Подробнее о доработках поговорим чуть позже).
Обучение
Существует 2 варианта обучения сотрудников работе с новым продуктом: это групповые занятия или обучение по 1-2 человека. Естественно, второй вариант дороже, но эффективнее. И здесь обычно решает руководитель, как его сотрудникам лучше учиться.
С групповым обучением, я думаю, все знакомы. Собирается группа сотрудников, чаще всего, это один отдел. Настраивается проектор или другой вариант большого экрана. А дальше я показываю и рассказываю, как в новой программе создавать нужные для работы этого отдела документы, как формировать отчеты и т.д. и т.п.
Намного интереснее обучение индивидуальное. Чаще всего я учу сотрудников компании попарно, т.к. это достаточно эффективно и позволяет экономить средства заказчика. Сначала я беру в работу одну пару, подробно все им рассказываю, показываю, отвечаю на вопросы. Далее, наступает очередь второй пары. И здесь мне ассистирует один из сотрудников, которые уже прошли обучение. Я читаю лекцию, рассказываю особенности работы, поясняю все нюансы. А сотрудник из первой пары показывает на практике, как выполнять то или иное действие. Также я говорю тем, кого обучаю, чтобы они не записывали мои слова, так как важно понять именно суть работы, а не заучивать алгоритм.
Таким образом, я добиваюсь сразу трех целей:
Далее, приходит очередь третьей пары. И здесь я беру в ассистенты сотрудника из второй пары и т.д.
Во время обучения очень важно наладить обратную связь
В работе бизнес-консультанта процесс обучения должен работать в обе стороны. Вы обучаете сотрудников работе с программным продуктом, при этом обучаетесь сами особенностям работы компании. Прислушивайтесь к тому, что вам говорят и о чем спрашивают сотрудники. На основе их вопросов и потребностей вы сможете также составить список необходимых в программе доработок.
Общайтесь с сотрудниками компании как можно больше! Не бойтесь диалога и не бойтесь показаться некомпетентным. Вас уже пригласили в качестве эксперта. Вам уже доверяют решение сложных и важных для компании задач. А знать заранее все нюансы работы конкретной компании вы не можете.
А потому не бойтесь фразы «не знаю». Если вы затрудняетесь с ответом, берите таймаут, изучайте возможности настройки программы так, как нужно для работы. И при необходимости фиксируйте доработки.
При обучении учитывайте гендерные различия сотрудников
Почему-то об этом очень часто забывают, потому я и выделяю этот важный момент. С мужчинами и женщинами надо говорить немного по-разному. Есть фразы и стиль общения, который будет прекрасно принят мужским коллективом, но в женском вызовет неприятие и наоборот. Учитывайте эти различия, старайтесь общаться с учениками так, чтобы им было легко воспринимать информацию. Это поможет в процессе учебы.
Никакой снисходительности при обучении!
Эту ошибку достаточно часто совершают айтишники (программисты, сисадмины и т.д.). Мне сложно судить, почему это происходит, но практика показывает: именно представители этих профессий чаще всего при обучении пользователей переходят на снисходительный тон. Да, конечно, вы знаете эту программу намного лучше, чем те, кого вы обучаете. Вы также намного лучше понимаете бизнес-процессы, которые планируете внедрить. Но те, кого вы обучаете, также взрослые люди, эксперты в своем деле. А вас именно для того и пригласили, чтобы вы решили те проблемы, в которых вы – эксперт.
Я могу понять системного администратора, который работает в штате, не имеет никакой заинтересованности в результате обучения, а пояснять в очередной раз, как ему кажется, азы, очень скучно и давно надоело. Но сейчас я пишу о другой работе. О работе бизнес-консультанта.
Вы в данном случае – не программист, даже если знаете эту работу в совершенстве. Вы – бизнес-консультант, который работает по проекту. А потому вы должны быть максимально эффективны, ведь вы ограничены во времени. И если к вам будет достаточно доброжелательное отношение среди сотрудников, работать с ними будет также проще на каждом из этапов вашей работы.
Напоминайте о том, что вы здесь – временно! Выполните проект и уйдете.
Достаточно часто, особенно, когда проект затягивается на несколько месяцев, сотрудники компании забывают, что вы здесь не навсегда. А потому стоит им напоминать, что вы в этой компании – не постоянный сотрудник, что вы уйдете, как только выполните свою работу. Это им помогает собраться и лучше воспринимать информацию.
С одной стороны, люди понимают, что вы уйдете, и спрашивать будет не у кого. И стараются выучить максимум полезной информации. С другой, когда человек понимает, что еще немного, и все дополнительные сложности окончатся, ему психологически проще учиться и воспринимать что-то новое.
Обучите своего преемника из числа сотрудников компании.
Я очень часто использую этот прием. В общем, почти всегда. Из всех сотрудников выделяю 1-2 человек, и концентрирую на выбранном сотруднике (сотрудниках) максимум усилий. Я больше с ним общаюсь, более внимательно подхожу к его обучению, уделяю ему больше времени, могу даже проводить с ним отдельно бесплатные занятия. Таким образом, я готовлю одновременно союзника для себя и мою замену на будущее, на то время, когда я уйду из компании.
Всех одинаково обучить невозможно. Кто-то все равно будет отставать, что-то обязательно будет забываться. И человек, который в мое отсутствие сможет помочь, напомнить или подсказать, будет очень кстати после окончания проекта.
Клиент видит, что он не будет зависеть от меня после окончания сотрудничества. Он понимает, что у него будет собственный сотрудник, который прекрасно знает программное обеспечение (почти как я) и в случае чего, всегда сможет помочь.
Сотрудник получает больше знаний и опыта, становится более ценным кадром для компании. Конечно, это для него – плюс.
Другие сотрудники понимают, что у них есть кто-то свой, коллега, к которому всегда можно обратиться за советом и помощью. Я – бизнес-консультант, мое время стоит денег, и сотрудники любой компании об этом постоянно помнят. А потому они часто стесняются задавать мне какие-то вопросы повторно, а своего коллегу переспросить всегда смогут.
Казалось бы, я лишаю себя дополнительного заработка. Но получить небольшую доплату за то, что вы повторно ответили на один и тот же вопрос, не столь интересно, как получить благодарного клиента, который вам доверяет, готов работать в будущем, и даже рекомендует вас своим знакомым.
Доработка программы
Как я уже писал выше, доработки проводятся в несколько этапов по мере необходимости. При этом очень важно выполнять только те действия, которые действительно нужны. Иногда бывает, что программист создает новый отчет там, где можно было бы настроить стандартный, просто потому, что так проще для специалиста и, понятное дело, дороже.
Я противник таких методов работы. Бизнес-консультант должен представлять интересы клиента. У вас общие цели: решить поставленные бизнес-задачи. И вы должны быть лояльны к интересам клиента.
А потому если в программе уже тем или иным образом реализован нужный клиенту отчет или документ, настройте и применяйте его. Единственное исключение из этого правила: клиент настаивает на определенном варианте реализации, при этом он поставлен в известность обо всех возможностях программы.
Также важно: не скрывайте от клиента, что вы – не программист, и доработками будет заниматься третий человек. На самом деле, вашему заказчику безразлично, кому платить деньги, вам или кому-то еще. Ему важно, чтобы сумма была адекватной, чтобы работа была выполнена качественно, и не требовала от него никаких лишних затрат времени и сил.
Я честно говорю клиенту: я не могу уметь все, а потому нанимаю для решения определенных задач узких специалистов. Также поясняю, что все вопросы я решу сам, от клиента потребуется только своевременная оплата и содействие.
Важно: обязательно перед этапом доработки нужно составить списки отчетов, которыми пользуются сотрудники при работе с текущим программным продуктом.
Все эти отчеты должны присутствовать в новой программе, причем, доступ к ним должен быть простым и удобным.
А программиста необходимо подключить к работе над программным продуктом как можно раньше, сразу же, как только у вас появятся первые задачи для доработки. Кроме того, старайтесь сделать так, чтобы до конца проекта работал один и тот же человек.
Важно: бизнес-консультант, который работает с малым и средним бизнесом, должен быть неплохо знаком с программированием.
Лично я достаточно хорошо знаю 1С-программирование, также знаком с веб-программированием, в частности, работаю с Drupal и с другими CMS. В процессе работы с программистом вы должны четко поставить задачу специалисту, а потом грамотно протестировать выполненную работу перед тем, как ее принять и показать клиенту.
Никогда не давайте прямой доступ программисту к вашему клиенту!
Даже если очень хочется, не стоит давать прямой доступ к вашему клиенту никому из специалистов, с которыми вы работаете. Клиент все равно не сумеет поставить задачу также четко, как это сделаете вы. А программисту будет спокойнее работать, если вы избавите его от любого возможного негатива.
Схема работы должна быть такой:
Вы получаете задачу от клиента – корректируете ее – передаете программисту техзадание.
И обратно:
Вы получаете работу от программиста – тестируете ее – передаете клиенту.
Достаточно часто клиент при обсуждении выполненных программистом доработок, выдает какие-то эмоции, в том числе, негативные. Ваша задача – принять весь негатив на себя, разобраться, что именно не понравилось и почему, передать в корректном виде требования по доработке программисту. Таким образом, программист избавлен от негатива и может спокойно работать, а клиент получает то, что ему нужно. И также доволен.
Консультант не должен злоупотреблять доверием клиента.
Консультант достаточно многое решает самостоятельно, «за клиента», но у него должна быть своя этика. Вы убеждаете клиента в правильности вашего решения, и он с вами соглашается. Но вы при этом также должны быть уверены, что ваше решение – оптимально. Помните, что нанял вас в качестве эксперта, который сможет эффективно решить поставленную бизнес-задачу. А потому у вас с клиентом – общие цели, и вы должны всегда очень внимательно относиться к интересам клиента, отстаивать их, искать лучшие продукты и методы, и, в результате, наилучшим образом решать поставленную задачу.
Написание документации
Итак, ваша программа работает так, как это нужно, сотрудники прошли обучение и готовы пользоваться новым продуктом даже без вашей помощи. Остается написать документацию.
И здесь также есть важная особенность. В отличии от разработчиков ПО, вы – бизнес-консультант. А потому и документация, которую вы будете писать для вашего клиента, несколько отличается от обычной инструкции по работе с программным продуктом.
Почему так редко используются обычные Руководства пользователя? В них много информации, которая не нужна большинству сотрудников. Найти то, что нужно здесь и сейчас, обычно достаточно сложно. В результате об этих Инструкциях вспоминают только в самых крайних случаях.
Лично я при создании подобной документации по максимум использую графику. Чаще всего, это графические нотации (IDEF 3, IDEF 0, Swim line и др.). Вы можете выбрать любой инструмент для создания таких графических инструкций, по своему вкусу. Главное – это результат. Кстати, избегайте упоминания нотаций, в которых вы будете делать описание бизнес-процесса, это информация не нужна клиенту.
Почему я предпочитаю графику? Возможно, вы слышали фразу, что одна картинка стоит тысячи слов. В этом все дело. Графика лучше воспринимается, ее легче запомнить. А потому любые рабочие процессы, которые возможно, составляйте в графическом виде. Используйте при этом стрелки, пиктограммы, но старайтесь не перегружать описание деталями.
Надеюсь, что я сумел в этой статье раскрыть различные нюансы работы бизнес-консультанта по внедрению программного продукта. Этапы переноса остатков, доработок и обучения очень важны для успешной работы. Потому я остановился на них настолько подробно. В следующей статье я расскажу вам о двух последних этапах, тестовой и промышленной эксплуатации программного обеспечения, а также о том, что происходит после окончания непосредственно внедрения.