Ускорение работы пользователей 1с
Разработки

Нужна ли доработка типовых конфигураций 1с?

Чаще всего возникает вопрос у руководителей организации, почему нужно дорабатывать программу 1с? Она что так не идеальна? Зачем она нужна? И кто отвечает за нее?
 

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

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

А вы верите, что программа за 3-15 тысяч рублей способна выдать нужный результат?

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

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

1с - гибкий инструмент автоматизации бизнес-процессов 

 


 
 

Оценка эффективности доработок

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



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

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



Если взять в основу обычный Activity Based Costing можно предварительно посчитать каждую стоимостную оценку:

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

2. Стоимость полная  — со всеми накладными (для персонала  — с фондами, арендой офиса в пересчете на сотрудника и т.д.).

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



 

Новое или лучше пусть остается так как есть

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

 


 
Лучше всего, если менеджер проектов имеет тоже экономическое (желательно высшее) образование. Иначе придется тратить много времени на выяснение вопросов и доказывания правоты с обоих сторон. А еще лучше аудиторское образование. Это позволит понимать с точки зрения проверки всей системы учета.

Довольно часто переход на новый софт производился только по тому, что платформа объемы документооборота и данных не тянет.

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

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


Кто будет выполнять контрольные функции за изменениями в программе?

 
Из книги Била Гейтса «Бизнес со скоростью мысли”, в главе  — „Кто должен быть хозяином электронных проектов” (стр. 323), пишет:"… По мнению главного исполнительного директора Johnson & Johnson Ральфа Ларсена, источник наиболее „эффективных” провалов, кроется, как правило, в том, что руководители бизнеса самоустраняются от участия в крупных проектах – ведь это такая тяжёлая работа! – перекладывая всю ответственность на подразделения ИТ или на внешних подрядчиков. Подобное абсолютно недопустимо,  — считает Ральф. – Опыт успешных проектов показывает, что все они осуществлялись под руководством специалистов в основной деятельности, а не по информационным технологиям. „Хозяином” проекта должен быть человек бизнеса, а задача службы ИТ – активно ему помогать. Проект не принадлежит внешним консультантам или службе ИТ. Он не принадлежит никому, кроме владельца предприятия”. 

 


Во многом процессом доработок и автоматизаций рулит отдел ИТ (отдел информационных технологий). Даже сейчас, когда формально назначаются лидерами проектов представители бизнеса, отдел ИТ все равно „мотор" как планирования, так и исполнения проектов. У отдела ИТ, как ни крути, навыков и опыта проектного управления и системного подхода больше. Правильно ли это? А нужно ли противопоставлять бизнес и ИТ. Истина в единении! Как и во взаимоотношениях главврача и завхоза больницы. Два мотора одного локомотива. Один мотор колеса крутит, другой  — управление обеспечивает. Задачи и результаты разные. В проекте должны быть два вектора, по возможности направленные параллельно. Руководитель от бизнеса организует выполнение бизнес-задачи, а руководитель от ИТ  — выполнение технических работ. Кому быть главным, зависит от людей и конкретных условий. С нашей точки зрения продуктивней, когда грамотный бизнес-руководитель. Но еще правильней когда они равноценны. Они ведь вместе строят целостную информационную систему предприятия.

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

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


 

Тройной контроль


 

  
Если рассматривать разработку на платформе 1С, уровня „система управления предприятием", то достаточно жизнеспособная система из трех составляющих: консалтинговая фирма, 1С-внедренец и конечно своя команда предприятия. Это достаточно дорогое удовольствие, но каждый элемент данной цепи не дает увести разработку-доработку в сторону двум другим составляющим. Если опустить такие тривиальные вещи как например определение четких итоговых целей доработки, по которым руководитель заказчика сможет оценить конечный результат внедрения. У каждой составляющей звеньев этой цепи свои цели. Консалтинг необходим, т.к. заказчик со 100% вероятностью попытается „натянуть" проект на старые бизнес-процессы предприятия или типовые. И почти любой внедренец 1С пойдет на встречу заказчику, обезопасив себя тем, что пропишет «хотелки" в техническом задании (ТЗ) и будет потом «тыкать" им при всяком удобном случае. Задача консалтинга  — пересмотреть имеющиеся бизнес-процессы и выдать независимую экспертную оценку, предложить альтернативу. Задача внедренца дать удобный инструмент для работы. А задача заказчика освоить принять разработку. И здесь немаловажным становится участие в команде заказчика сотрудника с высокими административными полномочиями.


Вывод

 
Многие решения 1С уже давно ушли от технологий внедрения «доработать рубанком". Появились продукты, успешные проекты, внедрения которых лежат исключительно в плоскости консалтинга. Это, например "1С: Консолидация", "1С: Документооборот» и т.п. По принципу  — «убери зависимость от программиста». Но мы до сих пор не можем полностью полагаться, что там все уже реализовано и именно так как нужно предприятиям. Хотя направление более чем правильное. Сейчас решения 1С претендуют на функционал без доработок. Вопрос только, когда это время наступит?

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

Надо помнить, что только установки информационной системы на рабочие места бывает недостаточно для полноценного запуска программы в эксплуатацию. Цель доработок - создать максимально удобную и эффективную учетную систему для бизнеса! 

«Тот, кто думает, что может обойтись без других, сильно ошибается. Но тот, кто думает, что другие не могут обойтись без него, ошибается еще сильнее»
Франсуа де Ларошфуко
 
 
 


Нравится 0 Не нравится
Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь. Мы рекомендуем Вам зарегистрироваться либо зайти на сайт под своим именем.
Добавить комментарий
Ваше имя: *
Ваш e-mail: *
Вопрос: Юзабилити - это удобство работы в программе?
Ответ:
Код: Кликните на изображение чтобы обновить код, если он неразборчив
Введите код: