Шанс на транзакционный учет

Как финансовому директору избежать ошибок при подготовке компании к внедрению ERP

Раздел: Управление финансами
Автор(ы): Виктор Прудковских, журнал "&.ФИНАНСИСТ" (№1, 2007)
размещено: 26.03.2008
обращений: 12798

Сколь часты заявления первых лиц компаний о начале внедрения ERP, столь редки затем рапорты об успешном окончании проекта. И не только на украинском рынке, это — общемировая тенденция. Но избежать превращения этого процесса в долгострой и добиться выполнения системой поставленных задач вполне возможно. Для этого компании важно уже на предварительной стадии проекта не допустить ряда ключевых ошибок, способных заложить основу неудачи всего процесса внедрения.
Когда в 1972-м году пятеро бывших сотрудников IBM организовали компанию Systems, Applications and Products (SAP), их видение выражалось словами «разработка стандартного программного обеспечения для обработки транзакций в режиме реального времени». И сейчас в это верят далеко не все, хотя сегодняшнее программное обеспечение лидеров рынка (таких, как SAP, Microsoft, Oracle и др.) позволяет сделать единую информационную систему реальностью. Собственный опыт автора (основанный на управлении внедрением ERP в двух компаниях разной сферы деятельности) позволяет сделать вывод о том, что успех или неудача проекта обычно закладывается еще до его непосредственного начала. А именно между выбором программного продукта и стартом процесса, когда описывается текущее состояние информационных систем, желаемое будущее состояние, а также подписывается контракт на внедрение и оговаривается сам процесс.

Когда начинать

Уверен, что у появления ERP* на предприятии есть лишь один глобальный предвестник: время. Время, пролегающее стеной между менеджментом и информацией. Впрочем, чаще всего можно встретить более детальную расшифровку:

  • несовпадение аналитики к данным о транзакциях, представляемых различными подразделениями. К примеру, программный комплекс по учету продаж в ритейле настроен по подразделениям, административные расходы в бухгалтерии — на основе валовых показателей, а руководство компании высказывает желание видеть расчеты на основе АВС (activity-based costing);

  • критичное количество локально используемых информационных систем (иными словами, проблема copy-paste — копировать-вставить). Например, продажи сети магазинов одежды учитываются в одной программе; склад — в другой; бюджетирование ведется средствами Excel, равно как и учет валютных операций, связанных с импортом; зарплата — в 1 -С зарплата и кадры 7.7 и т. д. В этом случае, чтобы ответить на вопрос генерального директора о том, каковы результаты «план-факт» анализа себестоимости проданных товаров, приходится «копипейстить» из нескольких систем в одну (чаще всего Excel) огромное количество данных, которые обычно имеют несовпадающие аналитические срезы;

  • отсутствие у головной компании детальной информации о деятельности подразделений, кроме финансовой и управленческой отчетности. Это — обычная проблема компаний начиная со среднего размера, которые имеют географически удаленные подразделения или даже достаточно большое количество подразделений в локальных пределах. Яркая иллюстрация: головная компания украинского пивного холдинга получает от производственного подразделения комплект бюджетных отчетов и основные формы бухгалтерской отчетности. На стадии предварительного анализа у головной компании возникли вопросы к внеплановому уменьшению транспортно-заготовительных расходов. Запрос от финансового директора «летит» к его же заместителю, отвечающему за контроль подразделений; от него — к директору подразделения; далее — к главному бухгалтеру подразделения. Хорошим результатом этого запроса будет появление в процессе уже post mortum («посмертного», то есть после принятия) анализа бюджета: «Евгений Степанович, так это потому, что мы добились от поставщика DDP (по ИНКОТЕРМС — «поставка с оплатой пошлины», где продавец несет все расходы и риски по транспортировке товара)».

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

Что предусмотреть в контракте

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

Одним потоком

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

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

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

Что означает на практике не предусмотреть такой пункт? Одна из европейских ресторанных сетей, действующих в Украине, при заключении контракта оговорила лишь процесс внедрения, обойдя вниманием дополнительные работы (предполагалось, что в Украине будет проведена адаптация системы, параллельно внедряемой во всей компании). В результате каждый запрос на изменения проходил как почасовая работа IT-специалистов вендора. Кстати, вовсе не от жадности последнего. Внедряющая организация планирует время своих сотрудников и, конечно, когда появляются непредусмотренные заказы клиентов на мелкие работы, просто вынуждена считать их по максимальной ставке. Как следствие, компания понесла не только повышенные затраты, но и, что более важно, незапланированные проблемы решались достаточно долго.

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

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

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

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

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

В качестве операционного управляющего проектом целесообразнее назначать представителя компании, а не привлекать на временной основе специалиста из компании-вендора. В последнем случае руководитель проекта будет поставлен на пересечении интересов вендора и клиента, что чаще всего только вредит проекту. К тому же такой специалист будет отлично знать программу, но не потребности компании, и лучше понимать аргументы внедряющей организации. Это кажется малой проблемой — потребности можно пояснить, интересы соблюсти. Но различия могут быть значительными. К примеру, один из моих проектов частично приостановился на 1,5 месяца только потому, что руководитель проекта (сообразуясь с информацией от вендора и будучи сам IT-специалистом) счел работы по фронт-офису завершенными, в то время как бухгалтерия компании считала иначе. В понимании руководителя проекта и внедряющей организации термин «работает» означал работоспособность программного кода и как максимум необходимость настройки: «включить функцию расчета», «добавить расчет НДС», «настроить расчет себестоимости по подразделениям» и т. д. В понимании бухгалтерии «работает» — значит можно учитывать транзакции, и результат будет соответствовать проектным требованиям. С учетом того, что проект осуществлялся в пяти странах одновременно, на ликвидацию последствий «коммуникационного сбоя» ушло более месяца.

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

3. Принятии плана-графика проекта и сметы внедрения.

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

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

На этапе внедрения обучение проходят лишь так называемые ключевые пользователи, обычно руководители подразделений или заместители, которые впоследствии должны проводить обучение остальных специалистов. Для быстроты и безошибочности дальнейших обучений учебные материалы должны быть максимально наглядными и полными. При наличии качественных учебных материалов функциональность системы можно изучать по мере необходимости. По моему мнению, нет ничего более наглядного, нежели видеоинструкции с аудиосопровождением, полный комплект которых размещен на внутреннем сервере компании. Это решение довелось видеть на практике — компания постановила, что данные о текущих покупках подразделений следует вводить в центральном офисе, где было создано соответствующее подразделение. В компанию одновременно на неполный рабочий день пришло несколько студентов, которые вместо специального курса обучения получили следующие видеоинструкции — «как ввести накладную на покупки сырья»; «как создать новый необоротный актив»; «как исправить сохраненную ошибку «неверное подразделение» и прочее, а также пару дней работы на тестовой базе (это несложно сделать силами программы Camtasia Studio, можно пойти и более консервативным путем — «скрин-шоты» и текстовые описания). Лучше добиться этого от вендора путем внесения требования о детальном руководстве пользователя в устав проекта, причем таким образом, чтобы на основе данных материалов проходило обучение ключевых пользователей. Это позволит внести в обучающие материалы необходимые изменения. Столь же важно изначально соблюсти принцип Майкла Портера — «все в сеть». Вся команда по внедрению должна обладать поразительной пропускной способностью, не задерживая даже на день решения ни одной возникающей проблемы. Как это будет сделано — удел конкретного проекта. Оптимальным является оснащение участников проекта ноутбуками и мобильным выходом на сеть по GPRS с помощью конференц-связи в Skype. Это даст им возможность обсудить возникший сбой при компиляции отчета о прибыли и убытках, а с помощью доступа к программе по серверу терминалов устранить его быстрее, чем при решении обычным способом. Именно проведением сначала ряда совещаний, посвященных сбору данных о возникших в прошлом месяце проблемах по проекту. А затем решения всех проблем в ходе итогового совещания. В данном случае первый вариант не просто экономит время, но и экономит деньги (достаточно взглянуть на почасовые ставки вендора; вспомнить о дополнительно нанятых на время параллельной работы сотрудниках старой и новой системы и т. д.).

Как избежать двойной оплаты «работоспособного функционала»

Отдельно стоит упомянуть следующую интересную практику. Многие западные компании начинают внедрение ERP-систем с России, Украины. Они исходят из предположения о том, что в этих странах количество операций невелико, и отработка проекта будет более легкой. Тогда, после относительно спокойного внедрения здесь, можно будет смело переносить систему на другие страны. Этому действительно стоит сопротивляться, поскольку недавно созданные филиалы еще не обладают устоявшейся юридической и организационной структурой, в них не отработаны бизнес-процессы. Поэтому анализ, предваряющий собственно внедрение системы, не покажет реальных потребностей компании. В итоге с изменениями внутри компании почти сразу после внедрения системы потребуются ее доработки. А значит, перенести данный опыт на другие страны напрямую будет невозможно.

Транзакционная схема

Данные полностью вводятся в ERP-систему в одной службе (чаще всего такой службой становится document processing) и затем детализируются, то есть учитываются в системе профильной службой. Например, осуществлена поставка хлеба в один из магазинов розничной сети. Document processing создает в системе документ «накладная» следующую информацию, необходимую любым пользователям, — дата, номер, сумма без НДС, НДС, подразделение, номенклатура, единицы измерения и т. д. Бухгалтерия видит эту информацию в системе и добавляет лишь данные о наличии предоплаты (чтобы система зачла ее); бухгалтер по налоговому учету проверяет наличие предоплаты и, обнаружив, что контрагент является частным предпринимателем на едином налоге, указывает системе отнести данную транзакцию в валовые расходы; планово-экономический отдел ставит себе на заметку уже сохраненную информацию об изменении в прямой себестоимости покупки, существенно превысившей обычную для данного подразделения цену и т. д.

Источник: информация автора.

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

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

Учесть требования всех ключевых пользователей

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

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

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

К сожалению, обычная практика далека от этого идеала. Чаще всего каждое подразделение готовит собственные требования к функциональности системы самостоятельно. Результат — как минимум затягивание проекта, что хорошо иллюстрирует следующий пример. В упоминавшейся ранее ресторанной сети внедрение функционала учета продаж (информация о транзакциях входила в систему из POS-терминалов) логично отнесли к фронт-офису. Было внедрено много улучшений: автоматизирована информация о реальном количестве клиентов и среднем чеке; автоматизирована передача внутренних заказов на изготовление блюд; увеличена детализация информации о нестандартных продажах (скидки, подарки и т. д.) и многое другое. Но финансовая служба в эти работы не была вовлечена. Только после подписания позитивных документов о завершении работ по внедрению учета продаж и в процессе обучения специалистов финансовой службы функционалу компиляции основной финансовой отчетности выяснилось, что записи налогового, бухгалтерского и управленческого учета формируются неверно. В финансах и налоговом учете в расходы включалось питание персонала без начисления налога на доходы физических лиц. В управленческом учете неверно учитывались нестандартные, например, акционные продажи. О бухгалтерии просто забыли, изменяя стандартный работоспособный функционал. Собственно, проблема сама по себе была несложной и требовала всего нескольких часов работы. Но специалисты вендора по фронт-офису уже работали над другими проектами, а у финансовой службы на это вообще не было предусмотрено время. В результате функционал полностью заработал лишь через четыре (!) месяца после выявления проблемы.

Всеобъемлющая роль финансовой службы

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

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

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

Для того чтобы финансовая служба была предварительно готова к столь активному участию во внедрении, от нее потребуются и дополнительные предварительные усилия по:

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

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

Об авторе:

    Виктор Прудковских, главный бухгалтер "Панальпина Уорлд Транспорт".

    Родился в 1978 г. Имеет два высших образования: в области финансов и в области права (КНЭУ). 2007 г. — по настоящее время: главный бухгалтер компании «Панальпина Уорлд Транспорт» (логистика — перевозки, таможенное оформление, проекты). 2005-2007 гг.: главный бухгалтер компании «Чили-Пицца» (сеть ресторанов средней категории). 1995-2005 гг.: бухгалтер, затем главный бухгалтер компании «Лелека» (розничная торговля продуктами питания).
    Опыт проектов в строительном бизнесе, оптовой торговле изделиями медицинского назначения.
    Автор ряда статей в журнале «Комп&ньоН».


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


ЧИТАЙТЕ ТАКЖЕ:
КНИГИ ПО ТЕМЕ:
Работа мировых рынков. Управление финансовой инфраструктуройРабота мировых рынков. Управление финансовой инфраструктурой
Искусство просить деньгиИскусство просить деньги
Сначала заплати себе. Превратите ваш бизнес в машину, производящую деньгиСначала заплати себе. Превратите ваш бизнес в машину, производящую деньги

Отзывы

Edward, e.fedorchuk@pro100.ua
Вот это правильная постановка. Часто приходилось слышать, что "источником информации для управленческого учета являются данные бухгалтерского учета". Хотя сколько раз говорилось об ограничениях бухгалтерского - это и достаточной длинный период в квартал, и запаздывание учетных процедур, и заточенность под требования государства, а не менеджеров или даже собственников, и требование документарного оформления... Хотя базис, который объединяет все системы учета - только лишь СОБЫТИЕ. А как это СОБЫТИЕ будет учтено в учете зависит уже от требований потребителей информации этого самого учета. Для себя так и называл подобный подход - учетом событий. "Транзакционная схема" понравилась больше
2008-03-26 11:53:01
Ответить

Sheridan, yar1976@bk.ru
Во первых, не 1-С, а 1С... во вторых слишком много "умных" слов ... в третьих, уже давно придумано управление по центрам финансовой ответственности... вопрос внедрения или не внедрения такого управления, вопрос компетенции менеджмента... и край ... т.е. учет в нескольких системах, как правило коррелирует больше с человеческим фактором, чем с производственной необходимостью. Например, в планово-экономическом отделе на руководящей должности абсолютно не компетентный руководитель... не одна ERP не поможет... и в конце концов, выбор информационной системы, это как написание бизнес-плана для всего бизнеса... если к этому руководитель будет подходить ответственно, поверьте моему опыту, все остальное дело техники !!!
2008-04-20 13:28:08
Ответить

виктор прудковских, viktorp@companion.ua
Уважаемый (-ая), Sheridan

Натурально я пишу, а не редактирую - это разные профессии. Это насчет "1-С" или "1С". Думаю, что можно опустить эту опечатку.

Позвольне не согласиться с Вами насчет того, что внедрение управления по центрам финанасовой ответственности самостоятельно решает вопрос. Ведь разделение по центрам финансовой ответственности влияет лишь на детализацию управленческого учета (в рамках или за рамками финансового). А на бухгалтерский учет по НСБУ или МСФО - нет.

А вот наличие некомпетентного руководства это реальное препятствие к нормальному внедрению...Но это просто не предмет статьи.

Спасибо за внимание, тема очень интересная.
2008-07-30 09:15:12
Ответить

Андрей, shaykan77@i.ua
Виктор! Спасибо за статью. Во многих моментах согласен с Вами. По поводу центров ответственности. Реалии отечественного бизнеса говорят о том, что выделение центра ответственности почти никогда не дают прав на самостоятельный выбор ИС. Даже если таким центром является крупное пром. предприятие (Это по поводу замечания уважаемого(ой)Sheridan).
По поводу удовлетворения всех пользователей. Прежде чем попытаться удовлетворить всех пользователей надо не только вовлечь представителей служб и подразделений в процес постановки задачи. Как снова таки показывает практика (жизненный опыт)сначала былобы здорово провести для этих представителей "курс молодого бойца". При этом в даний курс необходимо включить такие моменты как принципы работы ИС, задачи ИС (как общие так и конкретные на данном педприятии)+ научить данных представителей видеть не только проблемы своего подразделения, а смотреть и видеть (и понимать !)на уровне предприятия. Иначе на внедренцев будут смотреть как на врагов и пытаться всеми методами свести начинания по внедрению ИС к подходу "Ладно, мы будм работать в Вашей системе, только будем делать то, что делалли раньше просто картинка на мониторе будет другой". Жизнь говорит, что гораздо проще добиться понимания от высшего менеджмента (даже если он что-то непонимает)чем пробить стену нежелания, пасивного противодействия, а зачастую и лени рядового персонала.
Вобщем, я Вас понимаю.
2008-08-18 08:50:59
Ответить

виктор прудковских, viktorp@companion.ua
Андрей, к сожалению полностью преодолеть описанное Вами сопротивление невозможно. Всегда будут люди, которые будут стремиться в той или иной степени саботировать проведение изменений.
Топы должны быть согласны. Среднее звено - нужно вовлечь. Нижнее - приучить.
Описываемый же в статье вариант - это скорее техническая подробность к общей необходимости внедрения новой системы. Считаю, что лучше наладить один базовый учет, из которого остальные будут брать данные; чем делать несколько параллельных учетов. Вот и все.
2008-09-21 17:17:01
Ответить

Владимир, vlarus@ukr.net
Статья хороша.
Особо хотел бы отметить хорошо акцентированные автором (1) ошибочность распространенного мнения, что международные проекты лучше начинать с небольших "восточных колоний"; (2) практику совершенно различного понимания того момента, когда этап/подпроект "готов".
С другой стороны в статье, на мой взгляд, пристутствуют две мало связанные между собой главные мысли: внедрение ERP и транзакционный учет. Зачастую понимание необходимости транзакционного учета приходит к "топам" только на этапе внедрения ERP. Да и приходит оно зачастую от того самого среднего звена, которое как бы еще нужно "вовлечь", а на самом деле которое уже буксует без нужной информации для выполнения своей работы, мечется в поисках ее по всей плоскости своей горизонтали, вскрикивая "да, я тут придумал ..." подпрыгивает вверх и задержав дыхание "ни фига себе ..." ныряет вглубь, выстраивает какие-то схемы и схемки бизнес процессов и документооборота... Возникает вопрос, а кто или что мешает строить транзакционную модель учета "всего" без всякого ERP. Изначально готовить бизнес к тому, что все события должны быть учтены и найти своего аналитика. Тогда и любое внедрение будет не ломкой, а действительно автоматизацией. Да и коробочный продукт окажется применимым или почти применимым без снижающих его надежность вмешательств.
2008-10-14 11:50:37
Ответить

виктор прудковских, viktor.prudkovskih@gmail.com
Владимир,
По сути вы правы в том, что эти темы не должны быть связаны между собой так тесно, как это изложено в статье.
Но, к сожалению, в своей, оговорюсь - украинской, практике я еще не встречал компанию, которая бы внедрила модель транзакционного учета и работала в ней некоторое время до появления проекта внедрения ERP.
Поэтому и произошло объединение тем, которые логично было бы рассматривать отдельно.
2009-10-27 09:23:58
Ответить




МЕТОДОЛОГИЯ: Стратегия, Маркетинг, Изменения, Финансы, Персонал, Качество, ИТ
АКТУАЛЬНО: Новости, События, Тренды, Инсайты, Интервью, Бизнес-обучение, Рецензии, Консалтинг
СЕРВИСЫ: Бизнес-книги, Работа, Форумы, Глоссарий, Цитаты, Рейтинги, Статьи партнеров
ПРОЕКТЫ: Блог, Видео, Визия, Визионеры, Бизнес-проза, Бизнес-юмор

Страница Management.com.ua в Facebook    Менеджмент.Книги: телеграм-канал для управленцев    Management Digest в LinkedIn    Отслеживать нас в Twitter    Подписаться на RSS    Почтовая рассылка


Copyright © 2001-2024, Management.com.ua

Подписка на Менеджмент.Дайджест

Получайте самые новые материалы на свой e-mail (1 раз в неделю)



Спасибо, я уже подписан(-а)