DataLife Engine > Блог / Статьи о главном > Автоматизация бизнеса. С чего начать

Автоматизация бизнеса. С чего начать


17-11-2016, 00:52. Разместил: admin
Многие предприятия сталкивается с проблемами автоматизации бизнеса. И по-сути его размер не имеет значения. Даже у малого предприятия возникает ровным счетом столько же проблем, сколько у крупного. Чтобы выявить эти проблемы, нужно проводить периодическую проверку системы. Другими словами делать аудит программных продуктов, используемых в работе. С него и нужно начинать.
 

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

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

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

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


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


Ввод первичной информации

 
Прежде чем получать детальное представление о специфике бизнес-процессов по всем участкам предприятия, требующее автоматизации, лучше задаться вопросом как на низшем уровне будет или уже вводится информация в систему? 
 
В самом начале следует обратить внимание на формат ввода данных по поступлениям товаров (материалов, ТМЦ) в систему. На каждом предприятии этот этап присутствует. Потому рассматривать его лучше всего первым.
 
Еще до начала внесения в систему накладных вполне естественно следует определить формат работы со справочниками. Нужно четко понять действующую структуру, ее проблемы и пути модернизации. Это касается справочников «Номенклатура», «Контрагенты», «Статьи затрат», «Статьи движения денежных средств».
 
Мы рассматриваем справочники не как отдельную главу, только потому, что именно при поступлении в большинстве случаев и возникают новые элементы справочников. И здесь принципиально нужно строго и четко описать регламент ввода, порядок ввода и ответственных лиц, так как в дальнейшем от этого будет зависеть правильность работы на каждом участке системы и будет влиять на правильность ведения всего учета.
Например, диктат заведения номенклатур с первичных накладных поставщиков, может сильно загромождать систему, когда справочник формируется не из логики видения структуры ввода информации, которая нужна предприятию, а из логики – что в первичных документах отражено, то один в один будет занесено в информационную базу. И, если это именно так происходит, то следует этому уделить пристальное внимание. На практике всегда требовалась четкая структура позиций прайса, и даже ввод дополнительных материалов можно зафиксировать через учетную политику (!) принцип ввода информации.
 
На этом этапе самое важное – это заведение информации в базу. Чтобы она правильно заводилась, правильно хранилась, быстро обрабатывалась, быстро вводилась «первичка», быстро проводились документы без блокировок (транзакций), полноформатно формировались первичные печатные формы и контрольные отчеты первого уровня. Это первая линия автоматизации работы предприятия как на фронте. Если «передовая» будет работать быстрее, то все остальные процессы можно будет подтянуть. Конечно же, следующие этапы внедрения пойдут намного сложнее. Сами по себе данные нужно проверять, анализировать и контролировать. Все же следующие этапы попросту захлебнутся в неправильно заведенной первичной информации.
 
При переходе из старой системы нужно в первую очередь предусмотреть перенос справочников (номенклатура, контрагенты и остальные сопутствующие подчиненные справочники) и по возможности всех оперативных документов (поступление, перемещение, реализации и т.п.), информацию по ценам (установка цен). Предусмотреть отправную точку, с которой будут введены остатки в документ ввода начальных остатков (инвентаризация, оприходование). Следует пристальное внимание уделить этому начальному моменту. Еще на этапе внедрения нового это позволит сразу практически получить ответ на многие вопросы. Например, при огромном количестве номенклатур, справится ли новая система, будет ли быстро работать подбор номенклатур, получение цен и получение остатков. На практике при загрузке данных за несколько месяцев (даже год) это позволяло: увидеть, как ляжет вся информация на новую систему, выявить узкие места в новых функциях, понять, чем отличаются система новая от старой, чего не хватает, четко выставить параллель между ними. То есть не просто ввести пару примеров в новую базу, а именно загрузить ее максимально возможным объемом, чтобы заранее оценить способности новой платформы справиться. Часто сталкивались с тем, что в 1с7.7 скорость работы с формами намного радовала пользователей и «тормоза» работы с формами на новой платформе 1с8 не позволяла доказать целесообразность новшеств.
 
 


Далее в любом внедрении следует предусмотреть возможность ручной обработки и автоматической загрузки накладных от поставщиков. Плюс определить возможность автоматизации ценообразования на стадии прихода товаров. Это важно. И в большинстве типовых конфигураций это два разных блока: отдельно документ «Поступление товаров» и «Установка цен по номенклатурам». И в большинстве внедрений приходилось объединять эти документы, а вернее дорабатывать документ «Поступление товаров» для установки цен не только закупа (сравнения цен с предыдущими данными закупа), но по установке цен продаж по коэффициентам. Тем самым исключалось или, скажем так, уменьшались проблемы об отсутствии цен по новому приходу и осуществлялся контроль за изменениями цен в одно и то же время. При этом цен может быть не одна розничная, а целый комплекс из 3-х, 10-ти и более типов цен. Здесь важно также не забыть про контрольные функции по изменениям цен у поставщиков, торговых наценок по ценам продаж. Типовых инструментов в этом плане практически нет или не удовлетворяли полностью потребность. И главное выяснить, как это происходит в текущей работе.
 
Для автоматизации загрузки данных из файлов поставщиков (.xls, .csv,. xml, .txt, .mxl) также следует обратить пристальное внимание. Если таковые загрузки существуют, то их желательно сделать в первую очередь. Если нет, то отложить на ближайшее будущее после внедрения системы.
 


Выписка товаров, накладных

 
Дальнейшая проработка работы операторов — это наиболее важный момент при внедрении. Необходимо очень пристальное внимание уделить процессу, как это происходит в текущей системе. Записать, запротоколировать весь трудовой день «оператора» или нескольких «операторов» системы. Под «операторами» имеется в виду все, кто пользуется системой для ввода первичной информации. Это и менеджеры, операторы, кладовщики. Если их работу не автоматизировать полностью, то будет трудно доказать целесообразность внедрения. И тут очень важно организовать так их работу в новой системе, чтобы они почувствовали, что это будет для них лучше, чем было.
 
Как ни странно, но именно от этого для нас часто зависело, состоится внедрение или нет. И когда сейчас представляют на рынке новые продукты, мы сразу же можем оценить уже на уровне ввода первичной информации, где будут подводные камни при доказательстве, что система будет для предприятия полезной. На многих предприятиях практически, где мы делали автоматизацию, это было камнем преткновения. Где мы должны были в самом начале доказать, что в систему информация будет вводиться быстрее, чем сейчас или, по-крайней мере, не медленней. И здесь опускаются требования к формированию каких-то отчетов, это следующий этап доказательства. Главное, чтобы «оператор системы» за меньшее количество действий мог сформировать накладные. При этом обработки подбора типовые напрочь не подходили в работе. Ни одна не подходила. Для чего они существуют в типовых конфигурациях – это отдельная тема. В некоторых моментах они полезны, но не при выписке товаров – сугубо наше мнение, сложившееся на многих внедрениях. Практически на каждом из внедрений.
 
Ярким примером «неправильного» с нашей точки зрения ввода номенклатуры в документы реализация реализовано на новых конфигурациях платформы 1с8.3 такси. Быстрым подбором это не назовешь. Очень много лишних действий. Тогда как действия должны быть максимально быстрыми и позволяющими работать с максимально доступной информацией для принятия решения о подборе. К тому же без необходимости обращаться к манипулятору «мышь». 

 


При подборе номенклатур важно видеть остаток товара на складе (на нескольких складах) и цену (несколько типов цен) и обязательно в колонках, а не в отдельном выскакивающем окошечке при выборе номенклатуры, как это реализовано в типовых. Также важно, чтобы обработка подбора открывалась максимально быстро. Даже 8 секунд это катастрофично. Нужно добиваться скорости открытия подбора меньше секунды. Было так, что и секунда – это много.
 
Отметим, самое главное при начале настройки системы сделать так, чтобы количество номенклатурных позиций в тестируемой настраиваемой базе было ровно таким же, как в заменяемой системе с количеством остатков, ценами. Чтобы тест уже на первоначальном уровне показывал, будет ли система способна выдержать ту нагрузку работы при подборе. Пожалуй, даже этот пункт нужно указывать и настраивать первым. То есть, если система на первоначальном уровне не даст производительность с таким же количеством номенклатурных позиций, то либо система не так хороша, либо конфигурацию системы придется дорабатывать.
 
Большого объема информации не каждая может выдержать система. Например, при большом объеме номенклатурного справочника конфигурации «1с: Управление торговли 11.1» будет явно показывать отнюдь не чудеса скорости. Без доработки конфигурации не обойтись. Но и с доработками следует тоже держать ухо востро.
 
На практике, у заказчика один программист сделал систему подбора в справочнике номенклатура, чтобы была возможность видеть остатки по колонкам по нескольким складам и несколько цен. Сделал правильно с точки зрения написания кода (программирования). Когда это в базе было 10 позиций, все работало как часы. А стоило загрузить номенклатурный справочник 100 тысячами элементов, как сразу же выявились просто огромные тормоза системы. Стало быть, код не правильный. И это очень важный тест любой конфигурации. Но это не говорит в пользу типовых решений. Они также перегружены множеством ненужного кода и даже можем с уверенностью сказать, что не справятся с текущей задачей без вмешательства программистов.
 
Пусть внедренец покажет в новой системе, что там находится структурированный справочник в несколько сот тысяч позиций и, если она не будет тормозить, тогда действительно этот этап можно с уверенностью для себя отметить как благоприятный для дальнейшей настройки. Если же нет, то либо найти ему альтернативу через другие обработки подбора, либо отказаться от внедрения уже на первоначальном уровне. Это лучше чем оказаться в «болоте» при первом старте системе, когда обратной дороги уже не будет. Т.е. не важно сколько будет размер базы данных, сколько в ней будет документов. Важно сколько она выдержит количества номенклатур и будет ли работать подбор в документы на приемлемых скоростных условиях при увеличении объемов данных.
 
У нас, например, два способа подбора номенклатур. При большом списке номенклатурных позиций первый способ не оптимально показывает 8 секунд открытия обработки при наличии в справочнике более 200-х тысяч позиций. А при малых данных, открывается за секунду и позволяет более быстрым и удобным способом делать подбор уже внутри обработки с учетом характеристик номенклатур и серий. А второй способ идеально подходит практически во всех выборах номенклатур, но уже без характеристик и серий в списке. Оба способа являются нашим инструментами на выбор в зависимости от потребностей внедрений.
 
Работа «операторов» это маленький кусочек внедрения. Это верхушка айсберга автоматизации. Без этой верхушки самого айсберга не будет. Но и без аналитических отчетов будет любое внедрение катастрофичным. Цель автоматизации предприятия получить максимальное количество удобств работы в программе. Чтобы быстро получать отчетность. Чтобы контролирующие организации могли видеть результаты деятельности. Учредители — финансовый результат. Руководство каждого подразделения — отчетность на местах для принятия оперативных управленческих решений. Но когда еще только на первых этапах тестирования новой системы возникают проблемы: тормоза при открытии форм справочников и документов, не устраивает система хранения информации и скорость обработки, то отчетность теряет всякий смысл. Невозможно тратить огромные ресурсы на ввод данных. Этот момент самый болезненный и важный. Преодолев его и получив от системы требуемый уровень стабильности и производительности, можно дальше рассматривать результат – отчеты.
 


Отчеты первого уровня

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

 

На практике постоянно мы наталкивались на «грабли», когда требовалась переделка не только первичных печатных форм (накладные, торг-12, счет-фактуры, УПД, РКО и ПКО), но и типовых отчетов. И поэтому сразу устанавливалась наша линейка универсальных отчетов, которая в более расширенном виде позволяла контролировать данные. При этом эта линейка пригождалась на каждом внедрении независимо от специфик каждого предприятия. Везде требовались и отчеты по дебиторской задолженности, по контролю платежей контрагентов, анализ продаж и т.п. При этом отметим досадную вещь, что таких инструментов в типовых решениях почему-то не хватает, либо сделано не так как надо.
 
Например. Довольно часто кладовщики привыкают работать с товарным отчетом, который показывает остаток начальный, приход, расход, конечный остаток. И «Ведомость по товару», которая существует уже на основе универсального отчета, будет им крайне не удобна. Точно также как будет не удобна «Оборотно-сальдовая ведомость по счету» для ведения складского учета в конфигурации Бухгалтерия 2.0 или 3.0. Нужен четкий формуляр, конкретно приспособленный для быстрого получения ответа по движениям на складе без возможности кладовщику сломать какие-либо настройки. Универсальность инструмента (отчета) здесь будет играть злую шутку. К тому же им нельзя в принципе возможно либо видеть лишнего, либо уходить в более глубокую расшифровку данных. А ведь как дать кладовщику «Оборотно-сальдовую ведомость по счету»? Чтоб он что, смотрел информацию по другим счетам? Это полезно уже тем, кто будет анализировать информацию, а на «передовой» эта информация должна быть четко регламентированной. Процесс выписки товара и его отгрузки быстрым. Хотя, конечно же, все индивидуально для каждого предприятия.
Здесь же затронем тестирование новой системы. Невозможно пропустить этот момент. Потому как вышеуказанные вещи требуют, чтобы их обкатали на реальных пользователях, которые в этой системе будут дальше работать.
 
В самом начале внедрения новой системы не нужно забегать далеко вперед. Конечно, мы должны знать, что есть и существуют дополнительные возможности платформы, конфигурации программы для настройки создания систем более высокого уровня отчетов. Только вот перескакивать и на первых порах ставить себе задачу определения всевозможных систем планирования не нужно. Например, описывать бизнес-процессы финансового планирования. Это все тяжело ляжет на первоначальном уровне внедрения. Если конечно это не предусмотрено самой конфигурацией, как например в УПП 1.3 (Управление производственным предприятием). Только лучше такие новшества использования нового функционала, которого не существовало в старой системе, отложить на потом, когда справимся с первым этапом внедрения. Потому как первая настройка и первые тестирования на новой системе это далеко от реальности успешного внедрения.
 
Обязательно возникнут не учтенные моменты, которые и пользователи «неожиданно» вспомнят и не обнаружат в новом. Будет много моментов непонимания ими, где и как работать в непривычном интерфейсе, если он не привычен. А он будет не привычен! Курсы обучения обязательно помогут, но не на столько. Обучения на местах не избежать. Также как и не избежать ошибок в программном коде.
Во-общем, необходимо быть готовым к первым дням (месяцам) наплыва проблем. И здесь может помочь только глубокое тестирование всеми (!) системы на тестовой базе до запуска. Именно глубокое тестирование снимет большинство вопросов. «Отмазки» пользователей, что, мол, некогда тестировать, выльются в огромные проблемы при начале работы. Возгласы типа «меня скорее съедят заживо, чем согласятся еще чего-то тестировать» со стороны внедренца гарантируют наличие проблем при запуске.
 
И нужно быть готовыми, что и тестирование это не будет гарантией отсутствия полностью проблем. Самое важное, чтобы пользователи понимали, что это им нужно, а не тому, кто внедряет. Убедить в этом — нужно обладать не дюжими способностями не только способностями убеждения, но и на деле показывать все преимущества новой системы. И если преимуществ нет, то повторимся, не стоит и внедрять тогда такую систему.
 
Отметим, что типовой функционал в отчетах нам практически ничем не помогал в моменте автоматизаций предприятий. Да, существуют хорошие отчеты. Универсальный отчеты, которые могут показать результаты, заложенные в функционал. Только вот этого всегда оказывалось мало. Найдется с несколько десятков инструментов, которыми пользуются в существующей системе. Специфичных инструментов. К которым привыкли. И их нельзя упустить из виду. Как только произойдет внедрение, их спросят. Обязательно спросят. И либо предусмотреть, что они будут сделаны в ближайшее время, либо сделать их заранее. Уж лучше потерять год на настройку системы, чем потерять контроль за бизнесом. Как только «пережили» момент перехода, сразу же приступаем к созданию или донастройке системы отчетов.
 


Закрытие периода

В большинстве внедрений всегда требовалась помощь в том, чтобы закрыть расчет себестоимости, первый отчетный период, первый баланс и решение проблем первой настройки. Всегда могут возникнуть, что не так настройка была задана вначале и нужно подправить, перепровести все документы, найти ошибки в первичном вводе информации, исправить эти ошибки и сделать инструменты для дальнейшего их исключения. Да и к тому же возникают вопросы: «как закрывать?», «почему не закрывается счет 20?», «почему не распределяются затраты?». А также требуется полный контроль за вводом нормативно-справочной информации.
 
Само по себе закрытие периода очень похоже на то, что бросили менеджеров/бухгалтеров в «воду» и выплывай, как знаешь. В большинстве знания теоретические и даже практические не помогают в новой системе. Только тот, кто занимается внедрением, может досконально знать, как программа себя может повести с такими-то настройками и как это обойти или правильно выставить. И не то чтобы должен знать. Он может это выяснить: прочесть код программы, увидеть потоки информации как обрабатываются и куда направляются. И вот здесь, конечно же, нужно предусмотреть, что закрытие первого периода, а возможно и нескольких, нужно делать вместе. Иначе внедрение может попросту захлебнуться. И, пожалуй, это так всегда и происходит. Необходимо, чтобы разработчик, вернее внедренец взял на себя сообязательства в закрытии периода. А предприятие должно понимать, что типовой функционал еще не гарантия, что он будет работать правильно.
 
Например, очень тяжело искать ответы по расчету себестоимости по выпуску готовой продукции. Почему именно тяжело? Существует множество отчетов по затратам. «Ведомость по партиям», «Ведомость по НЗП», «Ведомость по производственным затратам», «Ведомость по выпуску», «Ведомость по затратам на выпуск», «Анализ распределения производственных затрат», «Анализ распределения затрат», «Ведомость по списанию производственного брака». И все они с первого захода не дают ответа куда деваются затраты: допустим, списанные НЗП. Собственно если касаться регламентированного учета (т.е. бухгалтерского), то там это легко видно, что затраты обязательно должны лечь на счета затрат, либо счета по претензиям и списаться. А в управленческом учете с первого взгляда так и не могли понять, куда же они подевались. В затратах их не находим. Так, где же они? Всегда предполагали, что списание НЗП списалось и распределилось на каждую номенклатуру. Делали мы списание документом «Списание НЗП». И потеряли эти затраты. Ранее делали документ по списанию через вид «Отчет по выпуску» и там указывали специальную статью либо по браку, либо общепроизводственные затраты и это находило отражение в «Ведомости по затратам», а здесь раз и после списания НЗП нет затрат. Списались и всё. Как будто их и не было. Разбираясь с конкретным случаем, мы увидели что да, списалось и больше нигде не появились. Это не бухгалтерский учет, где отражение идет если откуда будет списано, то обязательно найдет отражение куда списано. Либо мы учебный материал плохо учили, либо это познать только опытным путем можно. А потом поняли, а собственно это ведь управленческий учет. Раз списали, стало быть, зачем еще где-то это видеть. Ведь по-сути действие законченное. Век живи, век учись. Почему мы вдруг решили, что это все просто распределилось по партиям на каждую продукцию. Нас смутило, что движения по регистру «Затраты на выпуск» прошли в движениях документа. Пройти то, они прошли, а выходит, что они там просто списались. И только в инструкции мы поинтересовались и получили ответ: «если документ проводится только в управленческом учете – то УПП даже не поинтересуется – куда они исчезли….
 
Вот такие моменты внедренец может помочь найти или знать. И помочь их исправить-решить. А моментов таких на каждом шагу, тем более в такой конфигурации как УПП 1.3. Но и в других конфигурациях таких моментов предостаточно.
 

 

На вырост

Следует также учесть, что после полного запуска, когда пользователи уже более-менее стабильно работают и первичные отчеты снимают большинство вопросов, это не повод расслабляться. Все только начинается.
 
Внедрение – это не 1-2-3 месяца. Полноценная система внедрения предполагать должна дальнейшее сопровождение, доработку, помощь в решении возникших проблем производительности на местах, множества вопросов пользователей, а они все равно возникнут. Поэтому правильней назвать 1-2-3 года. Как это не грустно звучит, но это факт. Не бывает идеальных программ. Все они дорабатываются, обновляются. А если предприятие хочет расти, то расти будет и уровень автоматизации. И обязательно будут расти количество участков учета, требующих автоматизации.
 
Конечно, все зависит от возможностей внедренца и самого предприятия. Если внедренец/разработчик в состоянии сделать максимум работающего функционала на момент запуска системы, это хорошо. На практике происходит совершенно по-другому. Выливаются наружу и огрехи определения ожиданий от новой программы, описания требований и не правильного их выполнения. И даже предварительное тестирование эти моменты не снимает ни в коем случае. Это бесполезно. Они возникнут. Главное быть к ним готовыми. В процессе пути автоматизации постоянно будут возникать необходимость доработок и наработок.
 
 

 

Для чего нужна автоматизация


В самом начале кто принимает решение, что нужно автоматизировать? Руководство. А думаете, руководство полностью понимает, как работает каждый участник рабочего процесса на предприятии? Ведь на автоматизацию влияет не образное мышление, что, мол, мы производственная или коммерческая организация, возьмем, поставим «хорошую» специализированную программу, поставим и все заработает. Все складывается из мелочей. И в текущей наработанной системе таких мелочей складывается очень много в огромный комок переплетений взаимоотношений между подразделениями и сотрудниками, между контрагентами и собственными юридическими лицами. Все это невозможно описать и учесть сразу. Да к тому же все эти элементы взаимодействия постоянно находятся в движении. Бизнес-процессы меняются. И на определенных участках необходимы механизмы автоматизации, чтобы процессы не тормозились.
 
Поэтому четко сделайте для себя понимание: после внедрения нужно полное сопровождение системы не на один месяц и скорее всего не на один год.

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

«забуксует» в работе и остановится? Будет ли система отвечать тем требованиям, какие от нее требовались в самом начале? 

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

 

Нужно ли техническое задание на автоматизацию?

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

 
Эффективней сделать так настройку новой системы, чтобы при пошаговом изменении конфигурации уже в процессе создания было видно сравнение и выбор, в какой системе лучше работать, где требуется доработка. Именно поэтому мы технические задания не пишем, а работаем рука об руку со специалистом предприятия. Определяем первоначальные этапы дальнейших действий. И постоянно их корректируем по вновь возникшим обстоятельствам.
 
Работа в паре получается совершенно правильным симбиозом двух векторов знаний: знаний того кому эта система нужна и того, кто новую систему знает очень хорошо. К тому же отметим, что принятие решения перехода на новую систему не просто так возникает в желании руководства, это продиктовано тем, что есть элементы текущей системы, не устраивающие и не работающие как надо. Поэтому, какой смысл тратить время и все закреплять на бумаге, тогда как лучше вместе по каждому случаю настраивать новое.
 
Возможно, есть такой человек на предприятии, который способен описать все то, что находится в текущей системе. Это было бы здорово. На практике нам такое встречалось редко, а правильней сказать — никогда. Один человек работу всего предприятия досконально знать не может. Конкретный участок конечно он может знать хорошо. А вот охватить все в целом на предприятии — это достаточно тяжело. Опыт подсказывает, что такого никогда не было. Даже тот разработчик, который ранее запускал существующую систему и обслуживал ее многие годы. Даже он далеко не все сможет вспомнить, что было сделано и зачем доработано. Было бы хорошо, если он протоколирует все изменения, в самой базе делает заметки/комментарии, то это, безусловно, поможет. Правда, эти комментарии не будут подсказывать, где какая запятая в коде стоит, чтобы реально не упустить её из виду, и от которой зависит полноценная работоспособность того или иного участка.
 
Следует отметить, что чем больше было изменений в текущей системе, тем больше отдаляет необходимость это описывать. Лучше делать сразу и сообща в новой системе. У нас, например на одном внедрении за несколько лет столько произведено изменений, что ни о каком переходе даже не может идти речи. Это более 2-х тысяч изменений типового кода и плюс 500 новых объектов учета: справочников, документов, отчетов, обработок. И цель данного перехода далеко не оправдает те средства, которые будут затрачены на переход. Это будет настоящей проблемой. За столько времени было множество всего внедрено, наработано функционала и оптимизировано, столько усилий и денег потрачено. К тому же сделать практически один в один в новой системе явно не удастся. Методы и способы могут быть другими. Переход на управляемые формы в текущей базе и воспринимается как что-то не реальное.
 
Вот например. Даже переход с одного варианта-сервера на другой вызывают сложности. Решили перейти с файловой версии конфигурации Бухгалтерия 2.0, на PostgreSQL на Linux-сервер. Выясняли работоспособность торгового оборудования. С большим трудом решили данную проблему. Перешли. И оказалось еще множество «ниточек» что держало работоспособность на windows-сервере. Это работа с программой Exsel. Обработки по работе с поставщиками перестали работать. Обмен перестал работать между распределенными базами. Скорость работы пользователей упала. Отчеты стали формироваться вместо 10 секунд — 25 минут. Ну, вот скажите, разве это все предположить можно было? Скорее всего, да. Но ведь никто не вспомнил, где что работает и как. Не предположили, что это будет проблемой. Целый год тестирование проходило и настройка. Только из-за того, что много усилий потратили на настройку торгового оборудования, остальное осталось за бортом внимания и предполагалось, что это уж точно можно решить.
 
Ни в коем случае не нужно впадать в крайность. Техническое задание необходимо в некоторых случаях. Оно может быть не полным, вернее не столь детализированным, но должно давать вектор направления того, что необходимо сделать. И больше походить на план мероприятий — список необходимого для запуска системы.
 

 

Вывод

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


Хаки для Dle 10.4
скачать форекс советники Ilan

Вернуться назад