?

Log in

No account? Create an account

[sticky post] Это мы

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

Это взрослая жизнь. У нас такой опыт, что пора уже на пенсию, но все еще молодые. Поэтому мы делимся этим опытом друг с другом: профессионалами 1С и желающими ими стать. Наш опыт - как провести крупный проект от начала и до конца. Как зачать и выносить его, не споткнуться на мелочах, не попасть в крупные неприятности и добиться крупного, значимого успеха. Как применить прошлый опыт на новом месте; как работать с тем, чего раньше не знал; как изменить уже внедренный проект под новые технологии и измениться самим.

Как жить во взрослом мире 1С.

Все мы (или почти все) не только дружим в Интернете, но и работаем в одной компании, АйТи Капитал. Наш опыт не только индивидуален, но и коллективен. Также как и проекты. Также как и творчество в этом сообществе.

Мы также присутствуем на Facebook и ВКонтакте.

Типовая vs доработанная

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

 

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

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

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

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

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

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

А вы как думаете?

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

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

Зачем пишутся инструкции? Потому что, во-первых, так положено. Программный продукт должен сопровождаться описанием, а большой продукт – большим талмудом. Формальные требования ИТ-заказчика приводят к тому, что исполнитель, высунув язык, описывает каждую кнопку, каждую форму, каждую проводку. Кроме того, инструкции требуют и пользователи, опасаясь что после запуска их бросят на произвол стихии, а инструкция в их представлении это спасательный круг. Разумеется, чем он больше,тем лучше – авось там найдется и то, что поможет лично мне.

Почему их не читают? Главным образом потому, что требования формальны, а ожидания беспочвенны. Если проект должным образом поддерживается, то пользователи (как все нормальные люди) не хотят тратить время и усилия на чтение непонятных и устрашающих своими объемами текстов, а хотят чтобы им пальцем показали – жми сюда, получишь вот это. Также многие пользователи банально не знают, что есть инструкция и где она находится. ИТ-департаменту в этой ситуации тем более все равно, что будет написано в инструкции – главное, чтобы все работало, и жалоб не было.

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

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

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

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

Другие причины не так очевидны, но они не менее значимы. Любой крупный проект это слишком серьезное дело, чтобы пускать его на самотек. Как известно, учет и контроль – важнейшие составляющие управленческой деятельности, и в проектной деятельности это столь же верно, сколь и в других. Руководители проекта со стороны заказчика управляют своей командой, тогда как командой разработчиков они управлять не могут, а могут только согласовывать с ними параметры проекта.Это порождает неуверенность в способности другой стороны выполнить свои обязательства.Обычно отношения на проекте достаточно тесны для того, чтобы у заказчика возникло желание управлять исполнителями как своими собственными сотрудниками,продлить свои полномочия за рамки договора. Это неизбежно вызовет конфликт,т.к. во-первых, у разработчиков есть свое руководство, которое не потерпит урезания полномочий в отношении сотрудников, если это не предусмотрено договором. Во-вторых, в команде внедренцев существует своя система управления ресурсами, позволяющая ему (внедренцу) успешно решать параллельные задачи.Внешнее вмешательство способно подорвать эту систему, что вызовет ответные,зачастую не всегда адекватные целям проекта шаги. В-третьих, у команды разработчика есть собственное понимание архитектуры будущей системы и принципов ее построения. Для предотвращения конфликтов на этой почве необходимо постоянно информировать заказчика о планах, ходе проекта (текущей стадии), обсуждать достигнутые результаты и дальнейшие шаги. Чем меньше у заказчика опасений за судьбу проекта (и за свою собственную, это тоже надо иметь ввиду), тем меньше у него желания лично вмешиваться в управление им. В конце концов, если это работает – не трогай это.

Если ИТ-департамент вынужден заниматься всеми задачами информационного обслуживания компании, что вытекает из его предназначения, то основной, а то и единственной,деятельностью компании-внедренца является реализация проектов. Исходя из этого,у поставщика решения опыт в такой деятельности шире, глубже и объемнее. Приняв решение реализовать проект с привлечением внешнего поставщика, заказчик делает ставку именно на это, на специализированные знания и умения другой стороны, которых у его собственных сотрудников недостаточно. Следствием такого подхода, будет то, что видение проекта у обеих сторон будет отличаться. Попытка «продавить» собственную архитектуру командой ИТ приведет, в лучшем случае, к реализации ущербного решения, потере времени и денег. В худшем же случае, проект просто-напросто «не взлетит». Разрешение этой ситуации требует применения различных методов. Это и разъяснение, почему выбран этот вариант, а не тот, и ссылки на предыдущий успешный опыт применения выбранного решения, и выработка компромиссного решения с соответствующим изменением параметров проекта. Можно также обратиться к опыту специалистов из других областей – врачей, например – и просто объяснить заказчику, что предлагаемая им архитектура грозит проекту самыми серьезными последствиями. Разумеется, нужно уметь аргументировать свой прогноз – быстро,просто и доступно.

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

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

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

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

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

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

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

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

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

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

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

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

Человек, как известно, животное социальное. Общение с себе подобными есть одно из главных его занятий в жизни. Любой IT проект – не исключение. А уж взрослый проект состоит из общения не менее чем на половину, если не больше. Искусство общения с клиентом неоднократно описано в различной литературе, в том числе и посвященной управлению ITпроектами. Тем не менее в этих книгах зачастую не хватает фактуры, т.е. конкретных примеров ведения переговоров. А если они и есть, то они не учитывают исследуемую нами специфику – внедрение проектов на платформе 1С:Предприятия в крупных российских компания. В настоящей статье будет рассмотрен один пример из переписки компании «АйТи Капитал» с подобным клиентом.

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

Иван, привет!

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

Если что-либо непонятно – звони, готов голосом всё рассказать.

Самая главная проблема, которая нам мешает, и из которой растут все остальные – это то, что сначала был план на огромный проект и на много денег.Тогда мы составили ТЗ «на всё», с прицелом на миллионов ХХ плюс/минус У.

А недавно деньги резко уменьшились в три раза, а задачи остались такие же.

И сейчас нам надо придумать, как пролезть в игольное ушко – и в деньги вписаться, и проект сделать.

Это можно ТОЛЬКО при одновременном выполнении нескольких условий. Я лично обоснованно сомневаюсь в возможности обеспечить это совпадение. Посмотри, может ты сможешь гарантировать, что это возможно.

На что нужно обратить внимание?

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

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

А. Сначала напишу ограничения от заказчика.

6.         Из бухгалтерской системы1С он убирает и планирует перенести в другую систему часть важнейшего куска бизнес-процесса – учета реализации услуг. Получится кастрированный инвалид (риски описаны ниже).

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

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

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

В. Результаты анализа.  Ограничения и особенности проекта:

          Комментарий к особенностям 6:

Высокие риски запуска урезанного решения – с частичным учетом реализации услуг. Предполагается, что для этого будет использоваться другая система. Так как проект внедрения этой системы отложен, на этот период выставление документов планируется делать в Excel. Есть риск, что ключевые сотрудники Филиалов не примут такое ограниченное решение, в котором не будет автоматизирована основная торговая функция компании.

          Комментарий к особенностям 7:

Сложности с людьми в Филиалах. Есть риск, что на этапе внедрения новой учетной системы Филиалы будут генерить большое количество «шума» в виде «В новой системе нет привычных функций или они непривычно реализованы». Это потребует большого  количества нервов и  трудозатрат, как  для изучения проблемы, так и на разъяснения,что есть такие ограничения проекта. Им-то всё равно, что денег на проект мало,им подавай готовое решение. Так как для большинства Филиалов решение на платформе1С:8.2 «непривычное», потребуется большое количество консультаций, обучения,сопровождения пользователей на местах. Слабый уровень компьютерной грамотности может привести к тому, что пользователи откажутся пользоваться новой системой,ссылаясь на то, что она сложная, непонятная, неготовая, с большим количеством ошибок и т.д. и т.п.

          ОЧЕНЬ ВАЖНО:

Невозможно формально выполнить все работы из ТЗ,  чтобы уложится в урезанный бюджет.  Нужна реальная большая  работа. Например, нельзя  только установить типовое решение 1С и только провести обучение. Сама по себе новая система не заработает, какой бы простой и очевидной она ни была. Любой аудит покажет, что в результате работ  выполнены не все условия контракта.

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

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

·                Нужно, чтобы сотрудники Филиалов приняли ограниченную систему, в которой не будет автоматизировано выставление счетов-фактур, основная торговая функция компании. Этот функционал запланирован в другой системе, который будет ой как нескоро.

·                Железная воля Руководителя по подавлению восстаний в Филиалах из-за непривычного или ограниченного решения.Пока он не похож на того, кто сможет ударить авторитетом. Поэтому в случае«шума» какого-нибудь авторитетного директора Филиала у всех нас будут проблемы с разъяснениями. Например, почему счета-фактуры нужно делать в Excel и т.д. и т.п.

Ну и напоследок о такой мелочи, как стоимость :)

В ХХ/3 не уложится никак.

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

Быстро,кратко и наглядно.

Круг и масштаб задач, решаемых на платформе  1С, растет с каждым годом. Появляются новые инструменты и методики, зачастую, не побоимся этого слова, революционные.

Такой когда-то стала и расширенная аналитика учета затрат – РАУЗ.

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

Несмотря на это, часть людей (к счастью, небольшая), в особенности со стороны специалистов по внедрению, так и остались во власти стереотипов и продолжают упорно скрещивать копья в битве за традиционный партионный учет. Какие же доводы приводятся в защиту этой позиции? Следует отметить, что борьба идет, в основном, за метод ФИФО, списание по среднему окончательно сдано в архив:  

«Партионный учет прозрачнее и правильнее» – главный аргумент консерваторов. Вполне можно вручную рассчитать каждый показатель, увидеть историю его формирования по первичным документам. Действительно, с этой точки зрения партионная методика ФИФО, разработанная фирмой 1С, просто великолепна, но какова цена этой красоты?

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

В РАУЗе нужно привыкнуть «доверять» программе, и принять ФИФО с точки зрения той логики, которая в нее заложена. На нашей памяти генеральный директор одной торговой компании с большим оборотом и ассортиментом товара лично (!), с подозрением и скепсисом во взгляде, на калькуляторе пересчитывал вслед за программой себестоимость товара. Через пару месяцев, не найдя никакого «криминала» в результатах, он успокоился и полностью доверил программе эту трудоемкую работу.

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

На этом аргументация в пользу «традиционки» заканчивается, поговорим серьезно о «трех китах», на которых стоит методология применения РАУЗ.

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

Второй – точность. Многие не согласятся, однако сделаем оговорку: мы рассматриваем не только торговые организации, но и производственные, где для бизнеса единственным способом получить производственные отчеты со сложными итерационными бизнес-процессами будет использование РАУЗ (вспомним: встречный выпуск, многопередельное производство и т.п.)

Третий – гибкость и прослеживаемость движения. Это и возможность настройки глубины аналитики без существенной потери производительности (думаем, эксперты в архитектуры платформы понимают, о чем идет речь), и выбор параллельного/совместного ведения УУ и БУ. А самое главное – двойная запись, без которой в «традиционке» сумма может взять и «потеряться» на полпути между многочисленными регистрами.

Какие же выводы можно сделать? Безусловно, технология РАУЗ весьма перспективна, приносит существенные выгоды в сложном учете, отлажена и имеет солидный багаж успешных внедрений. К недостаткам следует отнести, в первую очередь, слабую отчетность и отсутствие удобных пользовательских инструментов анализа. Кроме того, технология еще достаточно молодая, специалистов и методических материалов мало, значительная часть сообщества настроена относительно консервативно. Кроме того, всегда находятся задачи, в которых без применения партионного учета не обойтись, например, если ведение расчетов по налогам жестко связано с учетом товаров (кассовый метод НДС).

Перефразируя известную шутку, можно сказать – вам не нравится РАУЗ? Вы просто не умеете его готовить.

Почему 1С лучше SAP

Сегодня предлагаю обсудить одну очень интересную тему: почему Большие Заказчики выбирают SAP, когда есть более надежное, качественное и гораздо более дешевое решение – 1С. Для начала давайте рассмотрим, что такое SAP с неформальной точки зрения, т.е. как это выглядит на реальных проектах, а не в пресс-релизах и хвалебных статьях.

SAP — дорогая 1С-ка немецкого происхождения для учета деятельности предприятий уровня Газпрома или РЖД. В широких кругах общественности бренд малоизвестен, его рекламу трудно найти в СМИ, но знающие люди постоянно сталкиваются со следами его (SAP) жизнедея-тельности и это уже успело породить массу «позитивных» откликов. Для некоторых людей слово SAP это просто синоним выражения «бешеное бабло». И, надо признать, они не так уж далеки от истины.

Как показывает практика, бывает такое, что дорогущие SAP-проекты оканчиваются пол-ным провалом и все начинается сначала. Однако это не останавливает Больших Заказчиков, и причина этого хорошо известна. Сообщение о внедрении SAP сразу же поднимает капитализацию публичных компаний. Что там происходит на самом деле ни акционерам, ни инвесторам неинтересно. А те, кому интересно, ничего не решают, хотя именно им приходится ходить по этому «минному полю» – не зря ведь специалисты SAP сами себя называют «саперами».

Про специалистов нужно сказать отдельно. Золотой лейбл продукта как царь Мидас превращает обычного программиста или консультанта в элиту офисного планктона. На других представителей планктона он смотрит свысока, 1C презрительно считает пьяной ошибкой сантехника Васи, случайно упавшего на ЭВМ. Конечно, наш брат за ответом в карман не полезет, поэтому все знают, что SAP это месть Гитлера за Сталинград, но это только полдела.
«Золотого» специалиста всегда можно отличить от настоящего по некоторым ключевым фразам. Все взято из жизни, даже придумывать ничего не надо.


  • Это плохой перевод с немецкого языка.  
  • Это находится в другом модуле. 
  • Как вы сюда попали? 
  • Хороший вопрос. Я хотел бы видеть, как это работает. 
  • Это будет в одной из следующих версий. Я не знаю в какой. 
  • Давайте попробуем и увидим, что получится. 
  • Этот вопрос относится к Базису. 
  • Я не знаю, эксперт будет здесь в понедельник. 
  • Это путь, которым предполагается работать!? Что вы делаете! 
  • Вы не должны это делать, но если вы это делаете, вызовите экстренную помощь. 
  • Доверьтесь мне, я знаю то, что говорю. 
  • Это — ошибка программы. 
  • Прошу позволить мне вызывать программиста из Walldorf’а. (село в Германии менее 15000 жителей, где находится компания SAP AG) 
  • Это будет в следующей версии, вы не должны модифицировать эту! 
  • Давайте определимся — сотрудник у вас ответственный или нет? Если нет, то о чём тут говорить?! 
  • Я думаю, вы там у себя в отделе договоритесь — кто комплектовал, а кто украл. Для нашей системы это не важно.

Что же такое SAP для людей, которые будут с ним работать? Какие впечатления выносят пользователи от знакомства с ним? Первое и самое сильное впечатление — ужас. Эргономика не выдерживает никакой критики, а об интуитивности интерфейса говорить даже не приходится. Задание логически связанных параметров разбросано по разным местам. Предназначение программ, полей ввода, колонок таблиц обычно никак не следует из их названий. Бывает и еще веселее: некоторые элементы управления программы появляются не в ее окне, а в меню клиента посреди его собственных элементов управления. Не знаешь – не догадаешься. Стоимость внедрения можно оценить, посмотрев на скриншоты с примерами форм, но – вы их нигде не найдете. По какой-то причине специалисты SAP стесняются публиковать все, что может навести Заказчика на грустные размышления. Разумеется, для ERP-системы «картинка» не главное, но за такие деньги можно было бы сделать и поприличней. Тем более что во времена изобилия визуальных средств разработки это не так уж и сложно. Ведь мы все отлично знаем, что есть системы, которые стараются идти в ногу со временем.

Наверняка у многих есть еще, что сказать по этой теме. Как говорится – милости просим.

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

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

Первая, она же главная, проблема лежит отнюдь не в технической плоскости, а в организационной. Специалисты компании-заказчика, представители бизнеса, которые ежедневно работают с данными и планируют перенести их в новую систему, обычно не видят сложности этой задачи и не придают ей серьезного значения. Очень часто можно услышать такую фразу: «У нас в данных все нормально». Естественно, сразу же хочется задать ответный вопрос: «Если у вас все нормально, почему же вы нас позвали?» Заказчик уже привык работать с плохо структурированными данными, часть связей между участками учета ведется вручную («учет в голове»), функционал учетной системы специально настроен на работу с конкретными, исторически накопленными ошибками в данных (ad hoc, он же «костыль»). Первейшая задача команды внедрения – выяснить в максимально возможном масштабе и «невзирая на лица» все основные нестыковки в существующих данных. Доверять фразе «у нас все хорошо» категорически не стоит. Каждая пропущенная ошибка ведет к увеличению трудозатрат на всю задачу миграции. Лучше потратить больше времени на обследование, но сэкономить время на перенос. Кроме того, рано или поздно обязательно обнаружится, что некоторые данные просто невозможно перенести в новую систему, так как они настолько запутаны, что на их «распутывание» уйдет не один человеко-год. В этой ситуации такими данными придется пожертвовать, принимать решение об этом должен заказчик и обязательно до начала проекта.

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

Отдельно следует упомянуть технические проблемы переноса. Обычно они подразделяются на два большие типовые ситуации: перенос из систем на платформе «1С:Предприятия» и перенос из иных СУБД. В первом случае можно (и нужно) воспользоваться конфигурацией «1С:Конвертация данных», использование которой значительно сокращает трудозатраты на перенос. Следует только соблюдать меру – некоторые данные дешевле и быстрее перенести вручную, чем тратить время на составление и отладку правил. Во втором случае целесообразно провести промежуточную миграцию, т.е. выгрузить данные из существующей системы в некоторое хранилище (файл в формате XLS, XML и т.п.), предварительно обработать их там комбинированным способом и потом загрузить в новую базу.

И, наконец, – last but not least – критерии завершенности. Ни одна задача миграции не может быть начата до того, как будут определены критерии ее завершенности. Обязательно, по каждому справочнику, виду документов, отчету, чему угодно должен быть определен список критериев, утвержденный заказчиком, по которому можно будет определенно сказать, что эта часть данных перенесена корректно. Критерием чаще всего бывают контрольные показатели какого-то отчета, уже существующего в системе или специально созданного для процесса миграции. Без таких критериев неизбежны ситуации, когда заказчик будет предъявлять претензии «вы должны были это перенести» и внятно ответить будет нечем.

Используя единую терминологию, разные люди вкладывают в неё разный смысл. Примером таких терминов являются «документооборот» или «управленческий учет».

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

Например, заказчик говорит: «Мне нужна система документооборота».
Консультант: «Отлично, у 1С есть подходящая типовая конфигурация для решения вашей задачи».
Заказчик: «Прекрасно, проведите мне презентацию решения» или «Подготовьте мне предложение по внедрению этого решения».

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

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

Клиент может вкладывать следующий смысл в понятие «документооборот»:
  • Согласование только определенного вида «внутренних» документов – договоров, заявок на оплату, заявок на закупку и т.д.;
  • Хранение электронных копий документов – фактически архив;
  • Учет факта получения бумажных оригиналов отгрузочных документов;
  • Учет передачи бумажных документов между подразделениями и т.д. и т.п.

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

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

Однако всё приходится начинать с начала, когда заказчики вдруг меняются в середине проекта. Но это уже совсем другая история…