3. Принцип наличия схемы бизнеса
4. Расширенный принцип IBM для автоматизированного учета
6. Принцип сохранения типовой функциональности
7. Принцип методической корректности
Введение
Внедрением 1С я занимаюсь с 2004 года. Преимущественно, приходилось заниматься бухгалтерским учетом, или околобухгалтерскими задачами в управленческом учете, а также непосредственно управленческим учетом в самых различных формах.
В ходе деятельности приходилось сталкиваться с самыми разными проектами — от простейших отчетов до сложных проектов с распределенной базой и двойным (управленческим и бухгалтерским) учетом, с автоматической генерацией хозяйственных операций, полной разработкой и внедрением схемы налогового учета по ПБУ18/02 в абсолютно нетиповой бухгалтерской конфигурации, и др.
В ряде случаев, приходя к клиенту с уже поставленным, но неправильно работающим учетом, достаточно было вдумчиво посмотреть на то, что происходит в учете, и нанести несколько точно выверенных «ударов гаечным ключом», после чего у клиента все начинало работать правильно..
Было несколько неудачных внедрений, которые стыдно вспоминать, и тем не менее — они дали свой, незабываемо ценный опыт.
С учетом полученного опыта, у меня сформулировались некоторые принципы ведения учета, которыми хотелось бы поделиться с уважаемым сообществом. Порой, постановка учета с соблюдением этих принципов позволяла мне решать сложные задачи с минимальными трудозатратами, получая решения, которые работали без проблем годами, обеспечивая удовлетворение клиентов и рекомендации.
Кроме того, все, виденные мной, успешные внедрения, при анализе, показывали соблюдение этих принципов. В то же время, их нарушение всегда приводило к проблемам внедрения (или сопровождения), и наоборот — анализ неудачных проектов всегда выявлял нарушение какого-либо принципа.
Конечно, соблюдение этих принципов, само по себе, не является единственным достаточным условием успешности внедрения — крайне важной является правильная организация, адекватная ИТ-инфраструктура, и многое другое. И вообще, критерии успешности у всех отличаются.
В качестве критериев успешности внедрения (внедрения, а не проекта в целом) я подразумеваю:
- — удовлетворение клиента результатом внедрения;
- — отсутствие постоянного потока проблем, инкриминируемых внедренцу (и, конечно же, требующих бесплатного решения в рамках «гарантийных обязательств»);
- — отсутствие упоров в неразрешимые проблемы, вызванные некорректным внедрением;
- — сохранение и наращивание сотрудничества по вопросам сопровождения текущих задач (обновления, профилактика, технический аудит);
- — рекомендации потенциальным клиентам и новым работодателям (при переходе сотрудников клиента на другую работу).
Я не рассматриваю здесь, как критерий, прямую коммерческую выгоду от проекта и своевременность оплаты, полагая, что эти вопросы успешно решаются на стадии планирования отношений, заключения договора или подписания документов.
Изложеное не претендует на идеальность, отражает мое личное, далеко не совершенное мнение. Применимо, по большей части, для автоматизации, на базе 1С, именно бухгалтерского учета, но вполне адаптивно для других разделов, да и примеры я приводил различные.
1. Принцип окупаемости.
Мне кажется, это главный принцип, по которому можно оценить успешность внедрения или сопровождения: Автоматизация должна себя окупать каким-либо образом.
А именно:
а) Постоянно приносить прямую или косвенную выручку.
Например, увеличить проходимость непрерывного потока покупателей за счет сокращения времени оформления сделок. Способствовать минимизации дебиторской задолженности за счет упрощения работы менеджеров, отвечающих за взыскание платежей. Способствовать более полному и быстрому удовлетворению спроса покупателей для привлечения их качеством обслуживания.
б) Экономить издержки, причем,на большую сумму, чем было затрачено на внедрение.
Содействовать сокращению связанного капитала (например, минимизировать складские остатки за счет эффективного планирования и распределения товаров). Сэкономить ресурсы пользователей, позволив им решать большее, или хотя бы, возможное, количество задач за ту же норму времени, и убрав с их плеч сложные расчетные задачи. Содействовать минимизации рисков налоговых взысканий (за счет своевременного составления и сдачи бухгалтером всей необходимой отчетности)
в) Позволять существовать бизнес-процессу, который окупает автоматизацию.
Например, позволять быстро и удобно осуществлять учет задач и рабочего времени специалиста-внедренца 1С (или фирмы-франчайзи). Без такового учета его деятельность невозможна, т.к. будут сорваны все сроки, забыты все задачи, недополучены все доходы, а ведение такого учета «на бумажке» все равно будет склонно саботироваться ввиду больших затрат времени и непрактичности.
Кроме того, окупаемость автоматизации присутствует как на корпоративном уровне, так и на уровне отдельных пользователей со стороны заказчика.
Автоматизация не должна делаться ради технологий, так, как в отсутствие внятных целей, и понимания корпоративной и индивидуальной выгоды, проект может быть саботирован на уровне исполнителей от заказчика.
В связи с этим, специалисту-внедренцу полезно провести с представителями заказчика разъяснительную работу, в ходе которой до их сведения будут доведены конкретные выгоды, которые появятся лично у каждого, а также запланировать автоматизацию таким образом, чтобы лично у каждого действительно появлялись выгоды, упростилась работа, загорелся свет в нелегкой трудовой жизни.
2. Принцип доверия
Автоматизированному учету нужно либо доверять и пользоваться им, либо сразу считать на бумаге и не делать перед кем-то вид, что у нас есть автоматизация.
Одна из главных проблем, с которыми приходилось сталкиваться у клиента: недоверие учету. Представим себе ситуацию: на предприятии внедрена автоматизированная система бухгалтерского учета. Группа пользователей работает в данной системе. Каждый из пользователей имеет около себя большой гроссбух, где ведет свой, бумажный, учет, а затем вносит оперативные данные в компьютер, и сверяет синтетику между компьютером и бумажным учетом, добиваясь соответствия.
В результате, пользователи делают двойную работу, у них не хватает времени на перепроверку результатов, они допускают арифметические ошибки, а потом героически их ищут. Как следствие, срывают сроки, жалуются на жизнь, программу и свою злую судьбу. В системе, по итогу, отражаются недостоверные данные, либо данные с нарушениями, не позволяющими использовать их в вышестоящих участках (например, неправильное ведение в «Бухгалтерии предприятия» НДС с авансов полностью дискредитирует идею автоматизированного учета НДС и составления книг покупок и продаж, а НДС с авансов, в свою очередь, зависит от корректности отражения взаиморасчетов с покупателями и поставщиками).
Бывает также, что пользователи начинают вручную, на калькуляторе, проверять данные вполне очевидных отчетов и агрегаций (что, впрочем, более подробно изложено в принципе под №4).
Указанное состояние можно охарактеризовать как недоверие автоматизированному учету.
Такое поведение пользователей, и как следствие, недоверие учету, могут вызывать следующие причины:
- — пользователь недостаточно обучен, не владеет системой в части своих участков учета – экплуатационно, и/или методически;
- — пользователь консервативен, не доверяет «этим новым технологиям, черт бы их побрал», предпочитает свои «проверенные и надежные» методы, сознательно саботируя автоматизацию;
- — пользователю неудобно пользоваться системой — какие-либо операции объективно необходимо считать на бумаге, т.к. возможности системы не соответствуют реальному процессу расчета (в основном касается нетиповых участков, или особенностей учета на предприятии);
- — система откровенно некорректно работает (что случается не только в заказном, но и в типовом поведении)
Основными следствиями недоверия учету являются:
- — отсутствие актуальных и достоверных данных в системе учета, т. к. усилия пользователей направлены не на обеспечение их достоверности, а на обеспечение дублирующего учета, заслуживающего доверия;
- — неэффективная работа пользователей, срыв сроков сдачи отчетности, недовольство автоматизацией на уровне пользователей, саботаж;
- — затягивание сроков внедрения, перерасход ресурсов специалистов и невозможность перейти к следующим проектам;
- — невозможность автоматизации отдельных участков учета, зависящих от нижестоящих участков;
- — недовольство руководства клиента итогами автоматизации, проблемы с оплатой работ.
Для обеспечения доверия учету необходимо устранить вышеизложенные причины любым доступным способом: произвести обучение, сделать пользователям работу в системе выгодной, довести до сведения лиц, принимающих решения, ситуацию, связанную с саботажем, обеспечить пользователям удобные механизмы для не типовых участков учета.
Также необходимо разрабатывать заказную функциональность без ошибок, и вести мониторинг проблем работы типовой функциональности, чтобы оградить пользователей от случаев когда система действительно некорректно работает.
3. Принцип наличия схемы бизнеса
Если у клиента нет схемы бизнеса — никакая автоматизация его не спасет.
Под схемой бизнеса имеется ввиду схема взаимодействия его составных частей, сложившиеся традиции ведения учета, понимание бизнес-процессов на своем предприятии, знание, как правильно отражать хозяйственные операции перед законом и учредителями.
Здесь, для правильной иллюстрации данного принципе, мне придется углубиться в длинный и распространенный пример из практики (помимо технической информации будет бухгалтерия и налоги)
В моей практике встречались сложные случаи автоматизации бухгалтерского учета единых холдингов , включающих в себя несколько согласованно действующих юридических лиц и предпринимателей. Например, когда в торговом бизнесе имеется следующие хозяйствующие субъекты:
- ООО, применяющее общую систему налогообложения (ОСНО), и торгующее оптом с НДС;
- ООО или ИП на УСН 15%, продающий товары бюджетникам, и иным клиентам, не требующим входящий НДС;
- Индивидуальный предприниматель (ИП), применяющий единый налог на вмененный доход (ЕНВД) и торгующий в розницу.
Товары в холдинге одни и те же, управленческий учет товаров (обычно, на базе конфигурации «Торговля и склад» или «Управление торговлей») осуществляется по общему складу, взаиморасчетов и денежных потоков – разделяется по хозяйствующим субъектам.
В общем-то все эти случаи делились на случаи, когда у холдинга имелась четкая схема работы, и когда ее не было.
Наиболее общей и серъезной проблемой такого примера взаимодействия хозяйствующих субъектов является распределение товара между субъектами.
В случае наличия схемы, товар, обычно, предсказуемо покупался на распределяющую организацию, с правильно и легально оформленной маркетинговой политикой дилерской сети (для избежания нарушений статей 20 и 40 НК РФ). Эта организация продавала товар на остальные хозяйствующие субъекты бизнеса по мере необходимости. Эти субъекты продавали товар конечным покупателям (менеджеры выбирали субъект продажи исходя из потребностей клиента и формы оплаты). Весь свободный остаток концентрировался на распределяющей организации, распределение товара, — вопрос чистой арифметики — выполнялось один раз в месяц, автоматически, специально написанными обработками. В бухгалтерию выгружались оформленные документы внешнего и внутреннего товарооборота, отрицательные остатки отсутствовали как класс (кроме небольших случаев оперативного пересорта). С управленческой точки зрения, товары двигались в одну сторону, деньги — навстречу, у организации была возможность абсолютно легального оптимизирующего маневра по НДС и налогу на прибыль, предсказуемое финансовое планирование.
Совершенно другая ситуация наблюдается там, где нет схемы. Товары покупаются хаотично, на любой хозяйствующий субъект, исходя из текущего наличия у субъекта денежных средств. Продаются менеджерами с любого же субъекта (как можно отказать постоянному покупателю купить товар оптом, когда он есть на розничной витрине?). При общем складе невозможно определить покупался ли товар на того субъекта, с которого ведется продажа. Соответственно, при выгрузке документов товародвижения в бухгалтерию, у субъектов, находящихся на ОСНО и УСН 15% (им это критично, в отличие от ИП на ЕНВД) возникала ситуация, когда продавался не тот товар, что был куплен, а тот, что был куплен — не продавался.
Вследствие этого, даже не рассматривая вопрос нелегальности такой деятельности и полного беспорядка в налогообложении НДС, финансовом планировании, погашении задолженностей, любой автоматизированный учет расходов для налогообложения прибыли оказывался невозможен, так, как продавался отсутствующий на предприятии товар.
При такой ситуации, представляется совершенно наивным мнение заказчика о том, что автоматизация может как-то устранить проблемы бизнеса. Обычно, в таких случаях, удается сравнительно неплохо автоматизировать оперативный торгово-складской учет, придав ему черты управленческого. Удается как-то первоначально поставить бухгалтерский учет (введя товарные остатки по данным последней, спешно «нарисованной» бухгалтером, инвентаризации), и более-менее эффективно решать по нему локальные задачи, при условии, что бухгалтер сам справляется с «краснотой» товарных счетов.
В описанной ситуации, проблемы начинаются тогда, когда клиент требует, чтобы ему автоматизировали распределение товара между хозяйствующими субъектами, что невозможно не из за плохо поставленного учета (как иногда думает клиент), а из за отсутствия легального (с точки зрения правоотношений и налогообложения) способа это сделать. Поскольку, например, товар, излишне купленный на ИП, применяющего ЕНВД, невозможно передать на ООО, применяющее ОСНО – иначе предприниматель «слетает» с ЕНВД в части этой сделки, и вынужден вести полный раздельный учет ОСНО/ЕНВД по всем правилам, что дискредитирует всю идею предпринимателя на ЕНВД.
Я не единожды наблюдал ситуацию, когда специалист брался за такую задачу, и по итогу не мог ее решить ввиду отсутствия теоретической возможности такого решения. Или задача как-либо, по эскизам заказчика, решалась (трудоемко и затратно), но, впоследствии, ее решение никак не помогало заказчику, который на этом основании пытался отказаться от оплаты работ, либо распространял среди других клиентов нелестные рекомендации.
Кроме того, проблемы распределения товара, в этой ситуации, нередко поглощают 90% времени и нервов бухгалтера. У него не остается времени на правильное ведение учета, срываются сроки сдачи отчетности, и нередко все это мотивируется, якобы, плохой программой.
Отсутствие схемы проявляется не только в рамках вышеупомянутой ситуации распределения товара. Так например, нередко у клиента отсутствует годная для автоматизации схема расчета себестоимости продукции, и для внедрения ее необходимо существенно доработать. Иногда автоматизация выявляет проблемы учета, которые раньше тщательно маскировались, или решались с недопустимыми упрощениями.
Таким образом, в ходе анализа проекта следует обратить внимание на проработанность схемы бизнеса, проверить, как она соотносится с возможной автоматизацией, и в случае, если имеются несоответствия, по примеру вышеизложенных, необходимо:
а) отказаться от данного проекта вообще;
б) указать на необходимость проработки клиентом отдельных элементов схемы ДО начала автоматизации, и дождаться завершения этой проработки, либо за оплачиваемое время, оказать содействие в проработке этих элементов (либо намекнуть на то, как эти элементы правильно организовать);
в) отдельно и документально оговорить отсутствие ответственности внедренца за участок учета, соответствующий не проработанному элементу схемы бизнеса.
Желательно, при этом, обеспечить предоплату :-)
В противном случае, можно столкнуться с ситуацией, когда выполненные работы не будут оплачены, либо недовольство клиента выльется в негативные рекомендации.
Существует также особый вариант сотрудничества, когда вы, помимо автоматизации учета, разрабатываете и внедряете заказчику схему ведения бизнеса. Однако следует помнить, что такая работа не должна осуществляться бесплатно, кроме того, на разработчика может быть возложена ответственность (в правовом поле, но скорее вне его), если будут проблемы с государственными органами, связанные с применением заказчиком вашей схемы.
4. Расширенный принцип IBM для автоматизированного учета
Девизом IBM является фраза «Компьютер должен работать, человек — думать». Впрочем, я встречал такую фразу в законах «Мерфи» и других источниках. Не знаю, честно, откуда она произошла. Но всякий раз, на моей памяти, когда этот постулат нарушался, у клиента в ИТ начинался какой-то страшный бардак.
Расширим ее для автоматизированного учета следующим образом:
«Человек должен предоставить данные, затребовать отчеты и провести анализ. Компьютер должен все сосчитать».
Типичным нарушением этого принципа является ситуация, когда бухгалтер, внеся реализации, пытается определить общую сумму продаж за период посредством вывода на экран журнала реализаций и суммирования графы «Сумма» на калькуляторе, вместо того, чтобы сделать отчет «Обороты счета», или вывести какой-либо более подходящий отчет. Также, тревожным признаком, предупреждающим о посягательстве на данных принцип, является частое употребление бухгалтерами весьма архаичного метода проверки прямым перебором, (который носит название «крыжить»), причем с использованием распечатанной информации на бумаге.
При правильно работающем принципе, пользователи вносят в информационную базу первичные документы, отражают иные хозяйственные операции, затем, посредством отчетов, проверяют по каждому участку учета некоторое количество «контрольных точек». Причем, данная проверка, по-возможности, должна сводиться к визуальному осмотру и формальному анализу данных без частого переключения между разными источниками.
Разумеется, полностью от использования прямого перебора данных отказаться, порой, невозможно, но все равно — это должно остаться крайней мерой, применяемой практически лишь при проверке правильности работы системной функциональности.
Задачей специалиста-внедренца является разъяснение пользователю методически правильного порядка ведения учета по участку, и доведение до сведения способов быстрой и нетрудоемкой проверки этого участка с помощью отчетов — «контрольных точек». О контрольных точках по НДС, взаиморасчетам и другим участкам я попытаюсь опубликовать отдельные статьи, и выложить сюда ссылки. Кроме того, некоторая информация будет представлена ниже.
5. Принцип замыкания
Учетная схема должна быть, по возможности, замкнута на максимальном количестве (реализованных в программе и целесообразных для постановки автоматизации) участков.
Указанный принцип можно рассмотреть как на техническом, так и на эксплуатационном уровне.
На техническом уровне данный принцип больше применим не к учету на регистрах бухгалтерии, а к учету на регистрах накопления (например, налоговому учету по НДС в любой конфигурации, учету взаиморасчетов в разрезе заказов и документов расчетов (для КА / УПП), и др. Он состоит в том, что остатки регистров накопления не должны бесконтрольно нарастать, «оторвавшись» от учитываемой сути действительности. Нарушение этого правила приводит к разрастанию информационной базы, замедлению ее работы, а также вызывает проблемы при свертке учета.
Случаи, когда регистры «разбегаются» в не типовой функциональности, оставим на совесть программистов соответствующих участков. Рассмотрим такую ситуацию в типовой.
Так, например, в конфигурации «Торговля и склад 9.2» ведется налоговый учет по НДС предъявленному и начисленному: документы поступления и реализации приходуют остатки в регистры «КнигаПокупок», «КнигаПродаж», а документы «Формирование записей книги…» — расходуют. В большинстве случаев учета в рассматриваемой конфигурации, налоговый учет по НДС никого не интересует — он ведется в бухгалтерской системе. В то же время, остатки вышеупомянутых регистров постоянно накапливаются, и переносятся при закрытии очередного периода, создавая дополнительные записи в информационной базе.
Кроме того, при использовании типового механизма свертки информационной базы, остатки этих регистров отражаются на дату свертки отдельными документами «Запись книги покупок», «Запись книги продаж» по КАЖДОМУ исходному документу покупки или продажи, с сохранением ссылки на этот документ! В результате, при свертке, мы получаем все исходные документы покупок и продаж помеченными на удаление (и не удаляемыми), по каждому из них отдельный документ «Запись книги…», и те же незакрытые остатки книг покупок и продаж на начало свернутого учета. Кроме того, сама свертка (если ее не доработать, предписав игнорировать эти регистры) может выполняться несколько суток.
При этом, решение проблемы элементарно — вводить каждый месяц документы «Формирование записи книги покупок» и «… продаж», и не забывать их перепроводить восстановлением соответствующих последовательностей.
Кроме того, можно вообще отключить формирование записей по регистрам налогового учета НДС, закомментировав несколько строк в глобальном модуле. Когда я в первый раз так сделал, перепроведя информационную базу за 2 года, то после упаковки таблиц обнаружил, что ее размер уменьшился почти вдвое. Иногда это «вдвое» перешагивает порог вынужденного дорогостоящего перехода с файл-серверной версии на SQL.
Аналогичная проблема встречается в системе «Управление торговлей 8» (в редакции 10 точно, 11-ю пока к сожалению не довелось полностью рассмотреть и внедрить) — налоговый учет ведется сам по себе, о его «погашении» никто не думает, остатки растут, пользователи «сталкиваются транзакциями» при проведении документов. Отключение формирования движений по налоговому учету НДС (закомментировать 10 строк в общем модуле) позволяет на четверть уменьшить размер информационной базы и ускорить проведение документов.
В бухгалтерском учете можно отметить ситуации, когда на счете существует беспорядок — красно-черная «гребенка» остатков, беспорядочно разбежавшихся между аналитическими объектами, относящимися к одной учетной единице.
Причем (для бухгалтерии 8) на счетах, имеющих субконто составного типа, иногда образуются «встречные» остатки по «пустому» значению субконто (пустая ссылка какого-либо типа) и «очень пустому» (неопределенному значению). То же самое с измерением «Подразделение» — встречается ситуация, когда часть движений прописана на пустую ссылку, а часть — на NULL (исправляется в режиме «Тестирование и исправление ИБ» в конфигуратора). В результате чего, типовые документы непредсказуемо видят или не видят остатки, просматривающиеся по отчетам, доводя пользователя до истерики (по оборотно-сальдовой ведомости товар есть, а реализация его упорно не видит).
На эксплуатационном уровне принцип замкнутости учета выражается немного по-другому. Сформулируем его так: Все используемые участки учета должны получать, по возможности, наиболее полные данные, и между ними должны быть разработаны и установлены контрольные точки для взаимной проверки.
Следование этому принципу позволяет сформировать учет, устойчивый к ошибкам и фальсификациям, полный и актуальный.
Рассмотрим пример формирования контрольных точек:
1. Необходимо правильно отражать движения по кассе и банку, (контрольные точки — соответствие учетных остатков банка выпискам, получаемым из банка, соответствие учетных остатков кассы ранее распечатанной и подписанной кассовой книге).
2. Это, в свою очередь, позволить минимизировать ошибки ввода первички по авансовым отчетам (контрольные точки — задолженность подотчетников) и товарным движениям (контрольные точки — взаиморасчеты с поставщиками и покупателями).
3. Ежемесячный аудит складских остатков и взаиморасчетов с клиентами также позволит минимизировать ошибки первички (контрольные точки — оборотки по сч. 08, 10, 41, 62, анализ субконто 62, отчет по выявлению отрицательных остатков на 10, 41 и т. п.), сверить материальные и прочие затраты, постановку на учет ОС и др.
4. Правильно введенные и учтенные взаиморасчеты позволят автоматически составить налоговую отчетность по НДС, в частности — по НДС с авансов (рассмотрено в иллюстрации к «принципу IBM»), встречно проверить товарные движения и остатки (контрольные точки — универсальные отчеты по регистрам НДС, сверка авансов и НДС с авансов, сверка данных регистров и бух. учета).
5. Своевременно запрошенные через телекоммуникационные каналы связи сверки по налогам, вкупе с п. 1. позволят поддерживать актуальное состояние расчетов по основным и прочим налогам, и контролировать своевременное их начисление (и отнесение на затраты) (контрольные точки — ОСВ по счетам учета расчетов по налогам и сборам, взносам).
6. Сверка бухгалтерского учета и налогового учета (по налогу на прибыль, УСН или ИП) позволяет проверить полноту и правильность учета принимаемых для целей налогообложения доходов и расходов (контрольные точки — отчет «Анализ соответствия бухгалтерского и налогового учета», «Анализ налогового учета УСН», универсальные отчеты по регистрам налогового учета ИП, ОСВ с включенными флажками налогового учета) .
7. Правильный учет по всем участкам дает надежную базу для автоматизированного заполнения всей регламентированной отчетности.
Каждая из контрольных точек может быть проверена формальным анализом данных, выводимых на экране в отчете. Каждый алгоритм такой проверки вполне можно дать пользователю под запись. Двойная запись бухгалтерского учета, или связь различных регистров накопления через типовые документы, являются естественным «проводником» замыкания, и изменения, внесенные в одном участке учета, немедленно «всплывают» в каком-либо другом, позволяя исправлять цепочки ошибок (или выявлять несанкционированные правки).
В незамкнутом учете никакие взаимные проверки невозможны, а свериться с первичными документами можно только прямым перебором.
Приведенный пример является не полным. В то же время, я надеюсь, смог донести суть — правильное замыкание учета позволяет разработать и использовать ряд контрольных точек, которые приводят к выполнению «принципа IBM», способствуют формированию доверия к учету, значительно облегчают внутренний аудит и исправление ошибок. Будьте уверены — если вы сможете дать бухгалтеру системное видение контрольных точек, позволяющих быстро и надежно отыскивать цепочки ошибок в учете, вы получите не только надежного и внимающего вам клиента, но и положительные рекомендации.
6. Принцип сохранения типовой функциональности.
При внедрении систем, для которых важно находиться на поддержке у поставщика (Бухгалтерия предприятия, ЗуП, УПП) необходимо максимально придерживаться типовой функциональности. Иногда можно использовать ее нестандартно. Если для какого либо участка целесообразно разработать нетиповую, то крайне желательно приписать ее «сбоку». Для подобных случаев удачно подходит термин «неразрушающее конфигурирование«, любезно и метко подсказанный пользователем с ником «Арчибальд».
Неправильно приписанная функциональность, или модификация типовой, значительно затрудняют обновление продукта, и заставляют клиента задаваться вопросами «а почему мы столько платим за обновление?» и «почему после обновления опять не работают участки А, Б, В, Г, Д…?». А также, разразиться гневным «Не присылайте к нам больше этого мальчика/девочку для обновления — он/она ничего не знает и нам опять развалит учет».
Для таких конфигураций, как «Управление торговлей» этот принцип менее актуален, т.к. в большинстве случаев, эта конфигурация вынужденно и глубоко модернизируется под оперативные нужды в угоду принципу окупаемости, а обновления ей не требуются. Хотя, с выходом нового постановления по учету НДС в 2012 году появились крайне нужные и важные документы «Корректировка поступления», «Корректировка реализации», достаточно глубоко увязанные в общие модули, и задача обновления глубоко переработанных решений на базе УТ, стала на короткое время крайне актуальной, острой, и авральной.
Отдельно и осторожно следует относиться ко внедрению и модификации конфигураций «Комплексная автоматизация» и «Управление производственным предприятием», так как они сочетают в себе элементы оперативного управленческого учета (который обычно и требует глубокой модернизации, затрудняющей обновления) и бухгалтерско-зарплатного (который требует регулярных обновлений). Если предприятие-заказчик может позволить себе длительное содержание штатного специалиста 1С, то этот принцип, вероятно, не столь актуален, т.к. штатный специалист (если грамотно построит свою работу) не так сильно и одновременно нагружен задачами обновления, как подрядный. Кроме того — штатный специалист является носителем схемы автоматизации, и может легко выделить из конфигурации нетиповую функциональность (приписанную им самим же) и перенести ее в новую редакцию без ошибок. Подрядный специалист занимается всеми клиентами сразу, а завтра он вообще уволится, и на предприятие заказчика придет другой, который (пока) не знает сути внесенных изменений. Что может вызвать далеко идущие и неприятные последствия, выявленные через длительное время после обновления, когда оперативная копия с неиспорченными данными уже недоступна.
Максимальное использование типовой функциональности позволяет:
- — легко накладывать обновления, даже силами специалиста небольшой квалификации;
- — переложить знание схемы учета на пользователя — т.е. решить вопросы сложных участков не программно, а эксплуатационно, а эксплуатационные знания дать под запись заказчику, а не замыкать программное «ноу-хау» на специалиста (впрочем, иногда нужно и это :-) ), вынуждая его постоянно держать в памяти особенности учета клиента;
- — использовать сравнительно надежный, для широкого спектра ситуаций (валютный учет, различные единицы измерения, особенности учетной политики), многократно протестированный интерфейс и код от разработчиков 1С, а не писать собственную поделку для сугубо частного случая учета.
В ряде случаев можно «выкрутиться», нестандартно применив типовую функциональность, или применив ее не по назначению.
В некоторых ситуациях совершенно невозможно обойтись без доработок. И здесь, конечно, целесообразно приписывать все изменения «сбоку» — используя подписки на события (для допроведения типовых документов по собственным регистрам), документы, вводимые на основании, регистры сведений (для хранения уточняющих сведений к типовым объектам), свойства и характеристики объектов, и др. – таким образом, чтобы обновление осуществлялось максимально просто, а использование типовых объектов в типовых же случаях не отличалось от официальной документации.
Также нужно отметить, что иногда (к сожалению, нередко) типовая функциональность работает неправильно (ошибка в релизе (или в ДНК методолога)). В этом случае следует понять идеологию, заложенную в типовую функциональность поставщиком, вмешаться в конфигурацию и восстановить ее работоспособность (например, откатом отдельных объектов метаданных на предыдущий релиз, или собственными правками, предельно минимальными и аннотированными). Пользователям же базовых версий рекомендуется предлагать (под запись) более-менее подходящий способ обхода неисправности участка ручными корректировками проводок и регистров.
Конечно, не следует забывать при этом о разумном компромиссе между концепцией неразрушающего конфигурирования и удобством эксплуатации, сохраняя исполнение следующего, по счету, принципа.
7. Принцип методической корректности.
Принцип, несоблюдение которого, по моему опыту, закладывает в ходе внедрения самое большое количество граблей.
Недопустимо решать локальные задачи не учитывая правильную методику ведения автоматизированного учета.
Ошибки такого рода, происходят, в основном из двух источников: от клиента и от недостатка знаний специалиста. Рассмотрим первое следствие:
Недопустимо позволить клиенту продавить неверную методику автоматизации учета.
В частности, если взять хорошего программиста от исполнителя и хорошего бухгалтера от заказчика, и при этом никто из них не понимает методическую суть внедряемой системы, то вместе они сделают из проекта неудобный в эксплуатации, трудно обновляемый и дающий ненадежные результаты, кошмар.
Если слепой поведет слепого, оба свалятся в яму (английская пословица)
В иллюстрацию данного принципа приведу длинный, но, надеюсь, заслуживающий внимания пример.
Некая фирма длительное время вела учет в системе «1С: Предприятие 7.7», используя глубоко модернизированную бухгалтерскую конфигурацию редакции 4.5. В общем-то несложный учет сочетал в себе оптовую и розничную торговлю (на ОСНО), элементы производства. Каким-то образом он был автоматизирован, у бухгалтеров сложилась схема работы, к которой они привыкли. Как это нередко случалось с бухгалтерией 7.7, подсистема регламентированной отчетности не использовалась (отчеты составлялись во внешней программе), законодательство в тот период значимо не менялось, налоговый учет по налогу на прибыль инструктивно совпадал с бухгалтерским, и не велся. Поэтому обновления, как таковые, были не нужны.
Однажды руководством предприятия было принято решение о переводе учета на «1С: Бухгалтерия предприятия 8» (редакция 2.0). Обойдем вниманием причины перехода — они были вполне обоснованы.
Организация пригласила для внедрения фирму-франчайзи, от которой был делегирован специалист (программист по профилю). Со стороны заказчика в проекте участвовала бухгалтерия в количестве нескольких человек.
Перенос остатков был осуществлен более-менее корректно. А потом начались чудеса. Так, как ни программист, ни главный бухгалтер, не обладали методической подготовкой по постановке учета в целевой конфигурации, бухгалтер начал требовать от программиста точного повторения функциональности версии 7.7, и привычных доработок.
При этом, программист абсолютно правильно и точно решал именно те задачи, которые ставил главный бухгалтер, при этом, не задумываясь о последствиях выполняемых изменений.
Для начала была неправильно настроена учетная политика, в частности — включен упрощенный учет НДС. «Этот ваш налоговый учет по НДС такой сложный, давайте просто документы будут попадать в книги покупок/продаж — у нас так было в семерке». То, что НДС с авансов пришлось формировать вручную — никого не смутило, так, как «в семерке тоже так было».
Затем было разработано несколько новых видов документов (связанных, преимущественно, с розницей), и исправлены типовые (реализация, поступление и пр.). Был существено поправлен план счетов, так, например, добавлены счета розничного учета товаров 41.13, 41.14, 41.15, по сути, различающиеся лишь классификацией складов с точки зрения управленческого учета (т.е. бухгалтерски учет на них был одинаковый). Напрочь переделан механизм расчета торговой наценки на счете 42 (конечно — типовой механизм не ожидал новых невнятных субсчетов, и работать отказался).
В общем-то уже на этом этапе информационная база обновлялась с существенными трудозатратами, а большинство автоматизированных механизмов, предоставляемых современной версией системы учета, было дезавуировано. Как раз тогда я пришел на новое место работы, был временно назначен на этот проект «смотрящим», ужаснулся, и попытался хоть как-то исправить положение. Но ввиду запущенности учета и консервативности бухгалтерии, мне, в общем-то, удалось исправить только несколько локальных ошибок в оставшихся типовых участках и навести небольшой порядок в доработках. После чего я перешел на другие проекты, но для интереса, наблюдал.
А через год случилось так, что ряд складов-магазинов предприятия, осуществляющих розничные продажи, перешли на ЕНВД, и потребовалось организовать раздельный учет ОСНО/ЕНВД по всем правилам. В это время, главный бухгалтер, вспомнив «семерку», продавил тому же программисту создание счетов 44.01, 44.02, 44.03 (Для чего? Для затрат ОСНО, ЕНВД и распределяемых, плевать что в статье затрат есть соответствующий реквизит, и написан соответствующий штатный механизм закрытия). «Ну как же — нам так удобно — сделал оборотку, и видишь затраты для ОСНО, ЕНВД и распределяемые — на разных счетах. У нас же так было в СЕМЕРКЕ….».
Соответственно, пришлось начисто переписать типовой механизм закрытия счета 44, так, как он был в шоке от такого вольного распоряжения типовым планом счетов.
Кроме того, ВНЕЗАПНО выяснилось, что распределение НДС косвенных расходов автоматически работать не будет ввиду предусмотрительно включенного, годом раньше, режима «Упрощеный учет НДС». А кроме того, не будет работать включение НДС в стоимость товаров / в состав расходов, для товаров, подлежащих продаже по деятельности, облагаемой ЕНВД — опять таки, ввиду того, что для этого требуются сложившиеся остатки партионного учета по НДС, который в режиме «упрощенный учет НДС» не ведется.
Соответственно, весь наиболее сложный НДС, кроме покупок и продаж (а именно, НДС с авансов полученных, НДС по косвенным расходам, НДС включаемый в стоимость/затраты), теперь ведется вручную.
В силу нововведений в НК РФ, у организации появились расходы, не принимаемые для целей исчисления налога на прибыль, и опять таки внезапно оказалось, что их надо учитывать вручную, т.к. постановкой налогового учета по налогу на прибыль никто не озаботился.
В 60/62 счетах на субсчетах расчетов и авансов — красно-черная «гребенка», (встречные дебетовые и кредитовые сальдо в третьем субконто, сходящиеся в договорах и контрагентах) соответственно, баланс автоматически формируется с искажениями в строках дебиторской и кредиторской задолженности. На 19-м счете тоже «гребенка», где дебетовое сальдо находится в разрезе документов, а кредитовое — по пустому субконто, что, вкупе с упрощенным учетом НДС, позволяет сверять книгу покупок с бухгалтерским учетом только «прокрыжив» не одну сотню входящих документов.
По итогу — ни один регламентированный отчет не формируется кнопкой «заполнить» так, чтобы не исправлять его полностью. Книги покупок и продаж составляются только после длительной ручной доработки документами «Отражение НДС к вычету», «Отражение начисления НДС» (для распределения НДС косвенных расходов и включения в стоимость / затраты). Налоговый учет по налогу на прибыль — не ведется, и налог на прибыль не рассчитывается. Механизмы автоматизации раздельного учета ОСНО / ЕНВД — не работают. Каждое обновление (которые делаются редко и по большим праздникам) выливается для специалиста в 10 часовую головную боль, а для предприятия — в издержки, и по сути — абсолютно бесполезно.
Из всех типовых механизмов, по сути дела, работает только журнал проводок и бухгалтерские аналитические отчеты. Работники бухгалтерии 90% времени занимаются тем, что вносят вручную и перепроверяют то, что автоматически можно было бы рассчитать одной кнопкой, и постоянно жалуются на то, как раньше в «СЕМЕРКЕ» было хорошо, а теперь как все плохо и как им трудно жить.
При этом всем, в проект были вложены гигантские (относительно своего размера и объективной сложности) затраты, которые были сосредоточены не на совершении минимально необходимых доработок и обучении персонала методически правильному ведению учета, а на решение потока локальных задач методом безудержного вмешательства в конфигурацию и наклеивания заплаток на все места.
В то же время, все, вроде как, работает. Программист — делал ровно то, что просил бухгалтер. А проект — объективно завален, так как нарушен принцип окупаемости, и затрат ресурсов бухгалтерии на ведение учета после внедрения стало, вероятно, больше, чем до.
Самое обидное, что таких проектов я встречал не один, и все имели примерно похожую историю: авторитетный представитель заказчика начинал «рулить» сколь угодно сильным программистом (но не имеющим методической подготовки). Программист решал поток локальных задач в точности так, как от него требовалось заказчиком. Но вместе, они доводили проект до ужасающего состояния — вплоть до перевнедрения.
Прежде чем внедрить решение задачи, следует изучить соответствующую типовую функциональность и методику ее применения.
Встречаются случаи, когда внедренец имеет недостаточную подготовку, и самостоятельно принимает методически неправильные решения, уводящие проект в сторону нетиповой функциональности и затруднения эксплуатации и сопровождения. Так например, ваш покорный слуга, в своем первом проекте по внедрению конфигурации «Управление торговлей 8» написал собственный механизм расчета розничных цен от закупочных по запоминаемой наценке, совершенно проигнорировав наличие аналогичного типового. Потратил при этом кучу времени, получив не очень надежный механизм, и даже не до конца отключил штатный, что начало вызывать проблемы при ценообразовании.
А всего лишь — невнимательно ознакомился с типовыми возможностями.
Правильный подход ко внедрению системы автоматизации учета предполагает наличие специалиста с методической подготовкой, знающего порядок ведения учета во всех типовых участках, и способного к тому, чтобы проанализировать нетиповые потребности клиента, и дать задание программисту по разработке изменений к конфигурации (или разработать их самому). При этом, изменения должны следовать вышеперечисленным принципам для того, чтобы быть удобными, полезными и окупаемыми.
Специалист должен обладать достаточным авторитетом и коммуникативными навыками, чтобы продавить клиенту правильную методику ведения автоматизированного учета.
Надеюсь, эта информация поможет при внедрении и сопровождении учета, и спасибо за внимание, если вы дочитали до этого места 🙂
Отличная статья! Автору 5+. =)
Все принципы действительно важны, особенно заинтересовали — третий (наличие схемы бизнеса у пользователей), пятый (принцип замыкания) и седьмой (методическая корректность). Считаю наиболее важным именно последний принцип, т.к. только постоянная ориентация на целостность всей системы учета при автоматизации любой ее части позволит достичь всех целей проекта внедрения, в частности, что немаловажно, доверия к автоматизации со стороны пользователей.
1.Принцип окупаемости – описана цель автоматизации вообще (автоматизированное место заменяет несколько «бумажных»).
2.Принцип доверия – если его нет, значит клиент не созрел, причем созреть должно обязательно руководство, а пересчитывать иногда очень даже нужно (принцип: Excel forever:).
3.Принцип наличия схемы – всё чётко в примере, у самого таких полно.
Как частный случай: с завода отпустили одну машину мешков сахара с документами, вторую без документов и дешевле, а продать всё это нужно ну скажем в детские сады по тендеру и с договором (выбираю вариант а);).
4.Расширенный принцип IBM – ну опять же помимо прочего научите бухгалтера основам Excel и он сэкономит кучу времени себе и нервов вам, повторюсь проверять по началу нужно, пусть даже для душевного спокойствия! Да и уметь проверять всегда пригодиться.
5.Принцип замкнутости – точно всё подмечено.
6.сохранение типовой – всеми руками за!
7.да это ж надо клиентам давать читать!!! Особенно тем которые брызгая слюной кричат «а я хочу что бы эта кнопка была прямо в центре табличной части!»
Зачёт по всем пунктам +10 (обещаю несколько раз продвинуть)
Тема статьи мне близка. Пару фраз в развитие приведенной классификации.
Принципы 1, 2 и (в определенной степени) 4 отражают социальный аспект автоматизации. При выполнении 2 и 4 окупаемостьдостигается почти автоматически. А эти принципы можно считать наполовину выполненными, когда бухгалтеры осознаЮт, что ОСВ — не единственный, и даже не главный отчет.
Принципы 3, 5, 6 и (опять-таки в определенной степени) 4 можно считать разбивкой/детализацией принципа 7. То есть методически правильная автоматизация должна накладываться не не хаос, а на внятный предмет-бизнес (принцип 3), должна быть комплексной (в терминологии автора — замкнутой), и надежной/живучей/устойчивой, чего нельзя достичь без сопровождаемости — важнейшей эксплуатационной характеристики. А сопровождаемость достигается при минимальности вмешательства в типовые механизмы («неразрушающее конфигурирование» — это уже в моей терминологии).
Коллеги, спасибо — я правда не ожидал 30 лайков за 4 часа и висения статьи в топе инфостарта 🙂
Рад, если статья чем-то помогла.
Отдельные моменты, и «контрольные точки» я попытаюсь отразить в других статьях в ближайшее время. Просто завал жуткий сейчас ввиду квартального отчета у всех клиентов.
Отмечусь по третьему пункту:
Очень часто мне приходится говорить заказчику, как правило руководителю, что автоматизация это не просто вливание бабла в компьютеры и программистов, а наведение порядка в умах. При правильной автоматизации зачастую вылазят все косяки существующих бизнес-процессов и документооборота, которые приходится исправлять или полностью перестраивать. Именно это зачастую и добиваются руководители начав автоматизироваться. Иначе начинаешь действовать по принципу «Дайте мне алгоритм бардака и я его автоматизирую, но автоматизировать бардак — невозможно»
По седьмому — такое вот неприятное состояние: абсолютно согласен со всем сказанным и стою на пороге нового проекта с неизвестной мне до селе конфигурацией. Понимаю, что без ошибок не обойтись и думаю как же их минимизировать. 🙂 Существующая документация, как правило, ни как не отображает сути методологии учета, а момент личного обучения не может быть затянут на неопределенное время. И как быть если рядом нет реального специалиста? Остается только вариант собственных ошибок. Очень тернистый путь, который и описан в 7 пункте.
Статья действительно супер! Все в точку! Даже добавить нечего. Часть примеров как будто я писала… С нетерпением жду продолжения.
Отличная статья!
Перед автором склоняю седую голову. С таким людями приятно работать, жаль правда, что в основном засилье у нас автоматизаторов из последнего параграфа — я тут просто код пишу, а после нас — хоть потом.
(6) «Вот этот вот молодой человек пришедший к нам недавно, много о себе мнит, пусть знает свое место и относится к нашей персоне уважительно!»
или посылай и уходи, или терпи, брат
(9) «в основном засилье у нас автоматизаторов» — а не правда ваша, заслабье это. плата за научить топов как вести бизнес в проектах не бывает
Всё в тему, даже добавить практически нечего — читал, и практически под каждым абзацем всплывал пример из собственной жизни.
(10) tango, так легко не дамся. Меня это только заводит))
Вообще есть реально запущенное дело, которое, если взялся, то нужно довести до ума, а если руководство само даст назад, то посчитаю, что толку нет и можно с чистой совестью искать другую работу, что и хочу в этом году сделать во втором полугодии, по ряду личных причин и держит только типа ответственное отношение к делу.
Если по публикации что нить сказать, то конечно все хорошо в теории, а как к практике так сразу человеческий фактор, кто-то в силу лет уже не учится, кто просто закаменел за рутинной работой… Если коллектив помимо того что профессионален, готов рисковать, то можно горы свернуть топая по своим ошибкам, лишь бы все были заинтересованы упростить себе жизнь в результате напряженно работы в течении некоторого числа месяцев. Дорогу осилит идущий.
(13) Brawler, для борьбы с человеческим фактором очень помогают понятия о управлении проектами. Лично по себе сужу, после того как стал стараться ставить SMART’ованные цели (кто не понял о чем речь, советую погуглить — это пересекается с темой топика) — на многое стал смотреть по-другому и вообще работу организовывать несколько иначе.
Еще маленькое замечание. Собственно говоря тут отметились люди, которые перестали быть просто кодерами, а уже реально занимаются управлением информационными потоками. При прочтении одной книжке по информационному менеджменту сделал для себя заметки по поводу Качества информации. Там всего 10 пунктов. я не буду их расписывать — первоисточника у меня нет, а на самостоятельную статью не созрел. В принципе в основном все и так будет достаточно понятно:
1. Уместность (релевантность) (чтоб не было как в английском анекдоте с воздушным шаром — «А мы где?» «На воздушном шаре»)
2. Понятность
3. Достаточная точность (замечу — не избыточная)
4. Полнота (перекликается с принципом Замыкания)
5. Достоверность (Что там о доверии говорилось)
6. Краткость
7. Своевременность
8. Адресность
9. адекватность выбранного канала передачи
10. Ценность превышающая затраты на получение. В ценность также необходимо включить такие моменты как обеспечение конфиденциальности, защищенности, чувствительность к ошибкам, обеспечение своевременности.
Собственно говоря, очень много из топика легко сопоставляется с этими критериями качества (что я кое где и пометил). Это с одной стороны. А с другой, уже давно понял, что составляя очередное, пускай маленькое техзадание, и помня об этих принципах — почему то оно получается лучше 🙂
(14) SMART’ованные цели))) ну когда-то в инсте что-то подобное втирали, но под другим именем.
Погуглил
Ну собственно все пять критериев оценки поставленной цели подвластны осмыслению.
Тоже не все, из того что втирали, сразу понял 🙂
Хорошая статья
Да, после прочтения в очередной раз пришла к невеселому выводу, что развивать автоматизацию надо не только снизу — с исполнительной и технической стороны, но и сверху. Как правильно отметили выше, побольше таких статей надо читать самим менеджерам. Может, распечатать и носить с собой, подсовывая под нос при требовании кнопки на табличной части))
Кстати, на внедренческом рынке есть и другой «принцип» внедрения:
Отличная статья !!! И как раз ко времени — распечатал в трех экземплярах
и подсунул бухгалтершам для заучивания… 🙂
А то прямо по тексту — куча доп.счетов из семерки и хотелка кнопок везде.
З.Ы. Скорее бы продолжение — успеть прочесть, пока не вляпались во что-нибудь…
(15) «переход он или состоится или нет» — он еще может «как бы состояться»
(18) сто пудов испортишь отношения, со всеми последствиями.
в общем, таков здесь (в стране пребывания) «бизнес»: владельцу надо чтоб все было тихо и чинно, учет отдается на усмотрение менеджеров (я хочу сказать менеджеров, а не продавцов), а тем надо себе бонусов получить: как следствие это мутная водичка оперативного учета, а бух учет — только в фискальных целях и полностью определяется адекватностью главбушки.
ну вот, и все причины «провалов» автоматизации. биться лбом об это — только из эфемерных (быстропреходящих) чуйств типа «профессиональное достоинство». результат: «сказали галку — сделал галку».
(20) «успеть прочесть, пока не вляпались», — поздняк метаться
«Владимир Путин поручил министерствам внести к 15 февраля в правительство предложения очередной налоговой реформы. Вчера глава Минфина Антон Силуанов объявил о начале «творческой» работы над реформой. Министр сообщил, что власти могут снизить прямые налоги и взамен поднять косвенные — то есть, например, снизить налог на прибыль, но увеличить акцизы или налог на добавленную стоимость (НДС).»
Отличная статья, читала с удовольствием.
Признак — отсуствие схемы — очнень знакомо,
а 7. Принцип методической корректности — КАК СТРАШНО ЖИТЬ/
Плюсанул. Все в тему, лаконично и по существу. )
Спасибо, за познавательную статью. Хороший обзор по всем пунктам автоматизации. Вопрос автору, как обрести методические знания, перейдя от простого программиста к внедренцу?
А это проверено на практике?
Спасибо, полезно.
Спасибо, прочитал с интересом.
(11) tango,
Зато я одно время сотрудничал с консалтинговой фирмой, которая на возмездной основе учила топов как вести бизнес — разрабатывала и внедряла всякие схемы. Ух, как же они красиво работали %) Ценник у них, конечно, был впечатляющий, но и результат тоже. Мне они скидывали всякие субподряды по 1С, в основном расчетного характера (т.е. перерасчитать в базе прошедший год в соответствии с какими-то вводными).
Хотя до работы с ними имел неплохой опыт по бухгалтерскому и налоговому учету, все-таки у них многому научился.
Кстати, одно время я пробовал разрабатывать схемы для клиентов, но понял, вскоре, что это дело неблагодарное. Во-первых, ты себя позиционируешь как специалист по автоматизации, и как налогового юриста, тебя, разумеется, всеръез не воспринимают. Во-вторых, отсюда проистекает меньшая оплата. В третьих, ты не можешь гарантировать свою схему, отстаивая, если что, клиента в суде у налоговой инспекции. В четвертых, невозможно поддерживать актуальность знаний во всех областях сразу — что-то начнешь упускать.
(11) tango, Плата «за научить боссов есть», назывыется коучинг. Но это совсем другая сфера, с автоматизацией практически не связана.
Спасибо, хорошая статейка
(26) angler225,
Да нет никаких особенных методических знаний. То, что есть, зарабатывалось разным трудом — высшим техническим, преподавательством, руководством собственной маленькой фирмой (инфраструктура + 1с), потом, уже позже — работой в более крупном франче. Ну и конечно, насмотрелся на около 100 разных клиентов за все время. 🙂 Слава богу, серьезно нигде не накосячил.
Мне кажется, что обрести методические навыки помогает не столько сам опыт, сколько системный анализ и наблюдение опыта, а также попытка не решать локальные задачи, а просчитывать варианты — что будет, если сделать АБВГД. Конечно, мне бы раньше очень помогли готовые формализмы по внедрению учета, но я, проштудировав разную литературу и пол-интернета, не нашел ничего, что могло бы помочь. Пришлось набивать шишки самому.
Мне самому нравится выражать свои знания в понятной для окружающих форме. Если кому-то эта статья пригодилась, что-то открыла, я рад — я достиг того, что хотел.
(6) Brawler,
Может мне как-то везло, за все время напоролся может быть только на одного бухгалтера, с кем я не нашел общего языка. Впрочем, она и без того задолбала всех спецов фирмы, где я работаю.
Некоторые, конечно, при первом общении начинают издалека гнуть пальцы, но примерно через 10 минут разговор автоматически переходит в конструктивное русло. Если разговор не переходит, стараюсь невербально показать, что я рад буду помочь только тому, кому это надо, и вообще, есть счеты, бумага, эксель, а у меня еще сегодня 3 клиента и работы полно.
(5) Спасибо! Казалось бы, как все знакомо! Несколько в другой терминологии, но по сути -так учили и в этом же утвердил собственный опыт. Прочла и ощущение как будто кто-то смахнул пыль с твоих знаний, добавил яркости в красках, рассортировал и упаковал, надписал и поставил на нужную полочку. Навел в твоем багаже радующий тебя порядок. Спасибо, интересно и доступно преломил общие теоретические принципы автоматизации в приложении к нашей работе, хорошая иллюстрация мысли в примерах. Отдельная благодарность за принцип замыкания — я этот часто момент упускала, особенно в регистрах накопления. Попробовала привязать названные принципы автоматизации к общетеоретическим :
1.Принцип окупаемости – принцип экономической эффективности
2.Принцип доверия – принцип достоверности
3.Приринцип наличия схемы – принцип системности, определенности и формализованности объкта автоматизации
4.Расширенный принцип IBM для автоматизированного учета — ?
5.Принцип замыкания — к 3?
6.Принцип сохранения типового функционала – принцип развития и совместимости.
7.Принцип методической корректности – принцип стандартизации и унификации
С интересом буду ждать новых публикаций.
на уровне автоматизации — руководители хотят сократить затраты (читай уволить работников с бумажной работы).
Люди не идиоты- понимают это.
Итак
этап 1) пришел- увидел- согласился.
Этап 2) Сбор информации (ибо те схемки нарисованные руководителями имеют мало что схожего с реальностью).
Этап 3) Написание бизнес процесса с учетом «особенностей».
Этап 4) Тестовый запуск — провал. (не полный а по многим пунктом много недочетов).
разбор- а при сборе информации оказалось что много «забыли сказать». И оказывается что есть правила о которых вообще никто не говорил. И НИКТО не догадается о таких правилах сам.
И тут возникает вопрос к руководству- что за ???? Мы пришли вам помочь а тут откровенный саботаж!!!
Не готовы предоставить достоверную информацию — давайте работать на типовой схеме! Нет слышим мы ответ — у нас очень специфический бизнес. После автоматизации 5-10 идентичных уникальных «бизнесов» понимаешь что проще сразу ломать схему без «прелюдий».
И не бывает внедрений с минимальными затратами и вообще без изменений схем бизнеса. НЕ БЫВАЕТ…. Хотя кому я это тут руководители никогда и не читают каменты.
Да и все общая практика когда после внедрения приходит фикси и хает внедренцев.
Как и почему- а все просто.
внедренец видит задачу — решает её- выгрузка из почти типовой в почти типовую УПП. решает её — пишет инструкцию как и что не стоит делать.
инструкция через пару недель бесследно исчезает.
меняется работник — и при следующей выгрузке он выгружает документ в «закрытый период» в базе приемнике. результаты описывать? Документы не проведены- движения есть справочники в которых ничего нет и прочая и прочая… Кого ругать? Себя что за что не проверил всю конфу лично? Пользователя? Конечно внедренцев!!!
Вообщем подводя итог — внедрение тяжкий труд и большинство выбора стоит делать правильно или дешево.
Что выбираете вы- и что выбирает руководитель?
Когда руководитель хочет универсальную автоматизированную систему от предатавляет это.
он крайне
а когда ты ему приносишь
озадачен тем что за «такие деньги» (произносить тоном мецената) сделали не то что он ожидал.
И получая ответ что за «такие деньги» (произносить тоном сборщика мусора на пляже в Таиланде) только это можно сделать — вы автоматически становитесь некомпетентной шайкой вымогателей и он нанимает того кто «проверит вашу работу».
(36) iov, Не бывает автоматизации без совершенствования схем бизнес-процессов. Даже более того — сама автоматизация — это способ совершенствования бизнес-процессов и наиболее удачный момент для этого. Еще на этапе предпроектного обследования необходимо не только изучить действующие схемы, но и по однозначно определиться какой будет схема в вашем проекте, максимально сблизив ее с типовой. Заявленная заказчиком уникальность в большинстве случаев всего явлется следствием или некомпетентности или непроработанности системы управления. Хорошо, когда на этапе предпроектного обследования в результате полноты сбора и систематизации информации критически оцениниваются бизнес-процессы не только разработчиком, но и зачазчиком (теперь перед ним полная картина), совместно прорабатываются варианты модернизации и он становится не только заинтересованным лицом, но и «первым руководителем» проекта. Есть такой принцип автоматизации — «принцип первого руководителя». Тогда есть реальный рычаг и опора и такие сложности как саботаж и т.п преодолеваются или волевым решенитем или мотивацией. Тогда отношения как к «шайке вымогателей» не будет и цена проекта в этом случае вопрос согласуемый. Хуже, когда это не происходит и все отдается «на ваше усмотрение», а потом работают «по своему усмотрению», и результат становится непредсказуемым и вцелом виноват остается разработчик. Это обязательно надо учитывать.
(38)Я за это и говорю что когда руководитель ПОНИМАЕТ и ДОВЕРЯЕТ — можно полностью исследовать, а когда его в течении месяца просто невозможно выловить и НИКТО не готов его заменить? Написано правильно — но это идеальное состояние абсолютно круглого коня в вакууме. Зачастую отдел бухгалтерии сегментирование по типам работ настолько что сотрудники не знают работы своего соседа. Или как например без подсказки узнать что документы поступающие от компании партнера поступают в PDF формате на сайт, откуда его забирает оператор и перемещает в определенную папку из которой его забирает задача описанная в планировщике как авто обновление сайта? Я говорю что нельзя все валить на внедренцев. Я сейчас фикси разгребающий проблемы после внедрения — и объективно я их понимаю а как фикси я ОБЯЗАН указать кто виноват и почему! И ведь указываю. Хоть понимаю что проблема была в том что мало денег — некомпетентные люди при постановке задач и непонимание бизнес процесса в целом.
Хорошая статья!
Спасибо автору!
Спасибо автору за статью, близко до боли. Сам постоянно сталкиваюсь с промблемами типа «сделайте так как я хочу иначе я вообще работать в ВАШЕЙ программе не буду и пойду директору жаловаться». А потом директор говорит «Дим ну ты сделай пусть заткнется, ну не увольнять же её из-за этого». ВОТ ТАК и идем на поводу у заказчиков а потом огребаем по полной когда говорят что наша программа не работает. Извините господа заказчика программа в первую очередь ВАША а не наша. Мы же Вам помочь хотим, а вы от нас информацию скрываете и сотрудники Ваши саботажи устраивают. Или когда говориш заказчику хочу удаленный доступ к вашему серверу и базе, а они а вдруг вы чтонить украдете и продадите. Извините господа заказчики если будет надо украсть своруем и без удаленки у Вас на глазах, но вся промблема в Том что никому ваша база не нужна кроме вас самих ну и внедрецев.
Вердикт следующий «читать надо особенно заказчикам», что б понимали, потому что когда я им подобные истории рассказываю думают что обманываю.
Спасибо автору.
Статья хороша, очень хороша. Может служить ориентиром для неискушенных внедренцев.
Интересно, спасибо
(39)
Бывает и другая проблема — когда денег много. Ну вот выделило руководство холдинга 20 лимонов на автоматизацию. А рыночная цена — 2 лимона. Как прикажете выкручиваться ИТ-директору? За что платить внедренцам — ведь все деньги надо «освоить»?
Выход один: провести тщательное обследование бизнеса, и по результатам обследования исковеркать хотя бы ключевые и отлаженные бизнес-процессы. Разрушить ту самую схему бизнеса, которая упомянута в статье. Восстановление позволит потом освоить и 20, и 40, и вообще, сколько угодно лимонов…
(44)Тут я выкручивался тем что закупал технику- тройная система резервирования и дублирования… 50% ушло на 3 серверных обеспеченных всем включая мини холодильник и кофе аппарат. А оставшиеся деньги были пущены в софт. А так согласен- был свидетелем того как компания интегратор получила много денег и при помощи аналитиков исковеркала рабочую систему. Бизнес развалился не могу утверждать что причина была именно в этом, но «посильная помощь» была оказана именно со стороны внедряющей автоматизирующей стороны.
А вот выделение денег без IT директора — это любопытно. Откуда цифру то взяли? Вот я тоже всегда удивляюсь тому насколько «осведомлены» люди в вопросах стоимости лицензий на софт и требуемых мощностях серверов. А клавишу insert самостоятельно отжать не могут.
(45) Деньги были выделены при пред-предыдущем ИТ-директоре. Предыдущий попытался разобраться в ситуации, но проработал всего 4 месяца. Сейчас выкручивается текущий.
(46) Аааа… А вот эот до боли знакомо…
мини холодильник и кофе аппарат Это хорошо ))
(47) Собственно, и статья получила такой отклик, потому что многим напомнила их жизнь.
(48) Их отжала бухгалтерия моментально… Но мы не расстроились потому что в холодильник максимум что влазило это пиво а кофе аппарат надо заправлять — а нечем. Зато в результате ошибки было закуплено 100 сетевых карт вместо 10 и ровно через неделю на свич уронили провод под напряжением — автомат сработал почти моментально — но 90 сетевых карт мгновенно выгорело. В результате за оперативность восстановления работоспособности премии и отгулы…
(49) Самое обидное что это не то что стоит вспоминать. Хотя может внукам и будет интересно то как мы бились с серверами и залатывали дыры после глюков 1С.
(51) У меня внук уже интересуется 😉
(52) У меня дочь до того как научилась нормально читать 13 символьный пароль набирала быстрее меня. Сейчас приходится дома права настраивать — 🙁 Блин у меня в её возрасте спички отбирали, я у дочери — роли…
Спасибо, прочитал с удовольствием. Четко и структурировано.
Статья лишний раз подтверждает, что сейчас на профильных ресурсах начинает «рулить» именно методика. Вот такого контента не хватает и на ИС и вообще в инете по 1С автоматизациям. Программить все в той или иной степени научились уже давно. Почти вся нужная и интересная техническая инфа есть и сведена в faq’и. Читай, постигай.
А вот теоретической инфы на уровне управления проектов, методик внедрения очень мало. Посему, еще раз спасибо.
(54) еще раз скажу — «заслабье»
потому что на «кочинг» топы согласны (лишь бы не работать), а чтобы какой-то 1снег их учил жить — это вряд ли
ну и получайте, чего хотите
не надо на прогеров сваливать ответственность за идиотскую организацию
Простые истины доступным языком!!!! автору большой плюс! спасибо.
Все про нашу нелегкую профессию
Спасибо. Хорошая статья, очень полезно.
Как хорошо описаны наши проблемы. Спасибо автору!
1.Принцип окупаемости – как можно посчитать косвенную выгоду от внедрения системы. ЗАчастую при начале внедрения происходит увеличения затрат а Заказчик как раз в этот момент ожидает эффекта от нее
2.Принцип доверия – без доверия руководства проект точно начинать не стоит. Очень опасно когда проект инициирует какой нибудь топ менеджер а руководству это не нужно. Тогда сдать такой проект очень сложно.
3.Принцип наличия схемы – это тоже не всегда работает. Хотя бы потому что за время проекта эта схема может поменяться и Заказчику плевать что вы уже все разработали. Потому как интересы бизнеса прежде всего.
4.Расширенный принцип IBM – ох хотелось бы всем опытных заинтересованных пользователей. Но так бывает редко.
5.Принцип замкнутости – сдесь согласен
6.сохранение типовой – тем более что можно сделать практически все отдельной объектной моделью. может вам и кажется сейчас что проще изменить существующий объект, но подумайте как вы потом будете это сопровождать когда уже забудешь что и зачем ты тут менял.
7.ага
ВАжно что бы проект внедрения был прибылен для Исполнителя. Тогда можно расчитывать (а хотелось быть уверенным) что он привлечет лучшие ресурсы свои и выделит их на нужное для проекта время. Нужно получить гарантии, что проект будет выполняться в монопольном режиме а не по остаточному принципу.
Да и бойтесь универсальных механизмов. это как автонажатие кнопки сделать все. Создание универсальных механизмов а не решение поставленной задачи погубило не один проект автоматизации
«В связи с этим, специалисту-внедренцу полезно провести с представителями заказчика разъяснительную работу, в ходе которой до их сведения будут доведены конкретные выгоды, которые появятся лично у каждого»
Извените это как? Затраты времени на новое обучение. И нужно ли оно юзерам и бухам? Так что саботаж или первоначальное отторжение новой системы сразу будет 90%.
«чтобы лично у каждого действительно появлялись выгоды, упростилась работа, загорелся свет в нелегкой трудовой жизни»
Премию руководство может и не выписать. И весь свет будет токо в том что их не уволят…
Очень хорошая полезная статья. Спасибо автору.
(64) Oleg1708, а обучение работе с новой программой за счет работодателя и в результате повышение своей квалификации и конкурентности на рынке труда — разве это не личная выгода.
вы все очень хорошо написали, по принципам учета, может вам стоит вести блог — по методике, было бы очень полезно. я например, тот самый программист, который пока не умеет продавливать логику учета.
Неплохо бы иметь описанный опыт внедрения УПП ил комплексной. Посто чтение дкоументации немного дает.
Очень правильные моменты подмечены в статье. Автор, пиши еще!
И когда можно ожидать «О контрольных точках по НДС, взаиморасчетам и другим участкам я попытаюсь опубликовать отдельные статьи»?
(66) ula1c,
Это будет и так за счет работодателя. Да и в + себе очень редко кто ставит. А говорит про это еще меньше.
В будущем юзеру может и понадобиться. Но текущие затраты больше давят чем будущие знания.
(66) ula1c (Юля?), о ком речь идет? О каком рынке труда?
Если о «рядовых» бухгалтерах, то позвольте возразить. Тенденция такова, что прогресс в автоматизации бухучета постепенно превращает эту профессию из массовой в невостребованную. Вот здесь это доказывается. Требоваться будут операторы ввода первички, которым не надо приплачивать за высшее образование. Интуитивно это понимая, бухгалтеры объективно (в некоторых случаях неосознанно) будут противиться прогрессу — за исключением тех, кто намерен сделать профессиональную карьеру, пробившись в бухгалтерскую элиту, которую сейчат власти пытаются создать.
Кстати, это универсальная тенденция — конвейеризация. Вспомним, с чего начиналось благосостояние США (по их собственному мнению). Это был переход Форда от изготовления автомобилей (инженерами и механиками) к их сборке малоквалифицированными слесарями.
Спасибо, хорошая статья.
очень интересно,спасибо:)
спасибо за отличную статью.
(70) Арчибальд, согласна и с тенденциями и с осознанным/неосознанным противлением, но реалии сегодняшнего момента какие?
На малых предприятиях главбух в одном лице — «и швец и жнец и на дуде игрец» — хочешь быть в профессии в своем ранге — будешь думать о повышении квалификации. Главбуха оператором не заменишь. Одно «но» -часто политику автоматизации учета на малых предприятиях определяет и диктует сам главбух.
На крупных предприятих сегодня в разряде «рядовые» бухгалтера —
1)грамотные и надежные специалисты, но не имеющие перспективы роста на данном предприятии, или часть из них не желает делать карьеру , 2)начинающая и пробующая себя молодежь, 3)люди случайные в профессии,она им неинтересна и перспектив для себя не видят,4)бухгалтеры пред и пенсионного возраста,когда мысль доработать бы до … (пенсии) становится главной, 5)тяжкообучаемые бухгалтеры, способные освоить операции на одном участке учета и не более . По опыту собственных внедрений скажу, что все они против перехода на новое программное обеспечение. И тут очень важным является позиция руководства. Кто из них готов уволитья? Противление сошло до нуля, когда поняли, что грядут большие перемены и успеть бы освоить новое, и если уж прийдется уходить, то со знанием и опытом работы в новой программе. Бухгалтеры тоже осознают,что сегодня это, как вы написали, «ключевое и единственное значимое» умение. Примерно через год состав бухгалтерии обновился наполовину. Ушли случайные и тяжкообучаемые — еще вначале внедрения, т.к. не способны или не хотели напрягаться. Ушли после освоения программы те, кто решил, что способен теперь на большее. И у них это поучилось. Чудеса твердости духа показывают многие предпенсионеры, тянут все, что на них валят.
К чему прийдем? К тому о чем вы пишите — будут главбухи (как вы называете — элита) и счетоводы (не нашла аналога этому термину в применении не к счЁтам, а программе (юзеры?)). Но так уже было. Эпоха перемен вызвала новый тип бухгалтера и,похоже, он постепенно уходит в небытие, оставаясь в нашей памяти. С уважением, Галина.
Вот люблю такие публикации. и сама статья интересная, да и комменты тоже почитать одно удовольствие. Все о наболевшем.
Соглашусь с предыдущим постом — часто не только политику автоматизации, но и вообще все, что хоть как-то относится к непосредственной деятельности малого предприятия определяет главбух. И очень часто бывает, что даже в этом случае в кресле главбуха (он же оператор, кассир, расчетчик, секретарь и зав.складом в одном лице) сидит молодая не обремененная интеллектом+опытом+образованием девочка с амбициями вице-президента. А тебе с ней работать… Она ни толком процесс описать не может, а часто даже понять, что от нее хотят, ни уж тем более хоть как-то формализовать свои требования. А потом звонит с вопросами, претензиями и понеслось…
все конечно интересно…. но боюсь что на практике очень частоююювсе не так ….с клиентами сложно работать
Такой объем здесь читать трудно. Сохранил. Посмотрю.
Не со всеми восторженными комментами согласен, но это потом.
1.Принцип окупаемости – принцип экономической эффективности
2.Принцип доверия – принцип достоверности
3.Приринцип наличия схемы – принцип системности, определенности и формализованности объкта автоматизации
4.Расширенный принцип IBM для автоматизированного учета — ?
5.Принцип замыкания — к 3?
6.Принцип сохранения типового функционала – принцип развития и совместимости.
7.Принцип методической корректности – принцип стандартизации и унификации
С интересом буду ждать новых публикаций.
Спасиба за инфу
Спасибо автору хорошая статья.
однозначно автору плюс за эпохальное творение!
даже перечитывать буду… приятно, когда мнение и ощущения специалистов сходятся, а это значит, что истина где-то рядом
Спасибо автору статьи!
А я из народа — я за типовые конфы!
спасиба афтару
я тож за типовые!!!!!!!!!!!!!!!!!
Хорошая статья. Действительно, внедрение-это совместная работа грамотных специалистов с обоих сторон — Заказчика и Исполнителя. Вот только сложно заставить пользователей смотреть по отчетам, что именно они наворотили в базе данных. Им проще записывать все на бумаге, чем сформировать отчет, например, по заказам покупателя, в котором нужно выбрать Клиента или Заказ. И пробиться через это нежелание очень трудно.
И еще одно замечание по поводу первой части статьи. Все дело в том, что на стадии знакомства с функционалом будущей системы разработчик работает с руководителями у которых, как оказывается потом, довольно идеалистическое представление о работе их подразделений. И сопротивление нижнего звена не стоит недооценивать, Вам будут кивать и со всем соглашаться, но простого контроля данных не будут проводить.
Спасибо за сформированные принципы внедрения, которые вырабатываются годами и опытом.
Перед автором склоняю голову. С таким людями приятно работать, жаль правда, что в основном засилье у нас автоматизаторов из последнего параграфа — я тут просто код пишу, а после нас — хоть потом.
чем типовее тем лучше)
Статья отличная, много правдивых слов от автора, впредь пиши такие же замечательные статейки!
Очень интересная статья
Спасибо автору статьи!
Статья хорошая, да. Автору — спасибо и похвала.
Отмечу так же жизненный комментарий (22), сам в такой ситуации нахожусь ((
(44) Арчибальд, (45) iov,
Возьмите меня к себе работать… пожалуйста.
(160) ни в коем случае… Художник должен быть голодным… Шутка — просто уважаю как разработчика и звать туда где самому не нравится — не красиво по крайней мере.
были настолько рутинные задачи — что я не выдержал и ушел… в более мелкую с зп поменьше — но зато не скучно и от дома пару шагов… И задолбал этот крупный бизнес — хорошо когда ты интегратор со стороны — пришел составил план — утвердил если они не выполнили свою часть — ответственность снимается…. А когда изнутри — ты еще и виноват что кто-то там ошибается в первичке… придумай так чтоб не ошибались… или к утру надо новую схему расчета бонусов по формуле которую дадут в обед….
(161) iov,
Как раз такая ситуация, только денег выделяют в десятки раз меньше.
(162) зато есть система учета — задача — счет — получение- исполнение.
и отчет на ком повисла задача — так вот 80% задач на оплате умирает.
так что жо прикрыта была… но работы нет — скучно…..
(37) iov, ну да. быть хорошим 1снегом — это очень даже далеко не все. надо уметь продавать
(180) да ну шо вы говорите… какой продавать таки от сердца отрываю… отдаю ниже себестоимости… (И ЧЕСТНЫЕ ЧЕСТНЫЕ ГЛАЗАМИ МОРГ-МОРГ)
(181) iov, не-а
надувать щеку надо так же, как покупатель
Cтатья порадовала. Жирный ПЛЮС.
И комментарии прочитал с удовольствием.
Полностью согласен с (38) -Не бывает автоматизации без совершенствования схем бизнес-процессов. Даже более того — сама автоматизация — это способ совершенствования бизнес-процессов и наиболее удачный момент для этого. Еще на этапе предпроектного обследования необходимо не только изучить действующие схемы, но и по однозначно определиться какой будет схема в вашем проекте, максимально сблизив ее с типовой. Заявленная заказчиком уникальность в большинстве случаев всего явлется следствием или некомпетентности или непроработанности системы управления.
Перед началом внедрения нужно максимально убирать бардак с схемы бизнес-процессов. Иначе после автоматизации получится АВТОМАТИЧЕСКИЙ БАРДАК ;).
На заре версии 7 тоже наступал на грабли подстройки под хотелки .
Результат — потраченное время и нервы… И не только свое .
(199) serge_focus, 25 лет в автоматизации бухучета, но никогда не была исполнителем «хотелок», потому что люблю свою работу и не люблю халтурить. Всегда потрачу время на изучение проблемы, обязательно перепроверю соответствие «хотелки» требованиям бухучета, прав ли клиент в своих пожеланиях. И не жалею о времени — полученные знания в дальнейшем выручат меня не раз. Считаю, что подсказать,показать, убедить клиента какой выбор правильнее сделать в данной ситуации- это тоже моя работа. И, слава Богу, никогда еще не столкнулась с клиентами-самодурами, всегда как-то удавалось прийти к взаимопониманию и доверию. Думаю ключ к нему лежит все-таки в уровне нашей квалификации в области деятельности клиента. Когда клиент перестает видеть в тебе только программиста, а видит «равного себе», то начинает уважать и доверять.