Началом всего внедрения можно считать событие почти годовой давности. Раздался телефонный звонок, и диспетчер слегка растерянным голосом произнесла: «Андрей, тут у меня мужчина. То ли я его не пониманию, то ли он меня. Не поговоришь?» После этого состоялась первая из полудюжины встреч с финансовым директором продюсерского центра, предваряющих начало разработки.
Центр занимается производством и продюсированием аудио-проектов. Процесс состоит из вложения финансовых средств в оборудование студии, запись, производство, маркетинговое продвижение на радио, телевидении и т.д. Кроме того, для этой деятельности характерны довольно существенные офисные, представительские, командировочные и прочие расходы. Доходная же часть получается от проведения концертов, выступлений в клубах, продаж лицензий, ведения спец. проектов и тому подобных мероприятий.
Пока центр только раскручивался, и проектов было немного, для учета всех финансов вполне хватало обычных таблиц Excel . Дело нехитрое: деньги приходят, деньги уходят – табличка доходов в разрезе по статьям, аналогично – табличка расходов. Таблички можно сравнить или диаграмму построить, а можно и вознаграждение сотрудника рассчитать. В общем, ситуация довольно типичная для любого начинающего бизнеса. Сам бизнес развивался, число проектов стало превышать число пальцев на руках, и тут начались трудности. Оценить состояние дел, проследить тенденции развития за последний год в различных разрезах владельцам бизнеса и его управляющим на простых табличках Excel , —увы, сложновато. Достаточно много времени приходилось тратить, чтобы сводить данные воедино, отсекая лишнее или вычисляя недостающее. Ну а самое главное, с развитием центра, с возникновением новых направлений, с расширением штата все больше сил уходило на рутинные операции.
Конечно, мы не в лесу живем - предложения на рынке финансово-экономического ПО достаточно разнообразны. Однако при внимательном изучении этих предложений топ-менеджеры центра начали понимать, что для освоения одной программы нужен солидный опыт работы бухгалтером, другая предназначена для производственных предприятий… В целом же, большинство средств автоматизации управленческой деятельности предлагает построение бизнес-процессов по определенной схеме, т.е. предполагает натягивание конкретного бизнеса на определенный каркас. Наверное, такой подход может быть вполне успешным для типовых видов бизнеса – оптовой или розничной торговли, общепита, автосервиса и т.п. Только вот готового каркаса для бизнес-процессов продюсерского центра не было.
Конечно, теоретически можно было бы выбрать какого-нибудь управленческого монстра – реинжениринг, маркетинг, управление рисками, бюджетирование, финансовое планирование, надо соответствовать мировому уровню …, но… с какой стороны ни подходи – задача-то изначально ставилась простейшая: приход-расход, надо просто зарегистрировать, а потом просто посмотреть – что из этого получается и принять простые и понятные управленческие решения. Неужели держать ради этого целый финансовый отдел, «кормящий» информацией ненасытного программного монстра, да еще и по определенной схеме? Есть ли в этом смысл, какая-то бизнес-логика? Смысла не находилось, и топ-менеджмент центра опять возвращался к табличкам Excel .
Итак, результатом первой встречи, о которой упомянуто в самом начале, стало определение функциональных границ нарождающегося проекта:
Следующая встреча уже была комбинацией экспресс-обследования и предложения возможных вариантов решения. В конце ее заказчик высказал пожелание подумать еще, боясь упустить что-нибудь важное.
И, поскольку «гнать коней» никому не хотелось, более чем за полгода состоялось еще несколько рабочих встреч. На них выкристаллизовался следующий перечень задач
От встречи к встрече росло обоюдное желание заказчика и исполнителя опробовать на данном проекте новую платформу »1С:Предприятие 8». Причин тому было несколько:
Стиль программирования на платформе «1С:Предприятие 8» в целом не отличается от того привычного стиля, который, как известно, называется структурным стилем «сверху вниз», то есть «с конца». Сначала были нарисованы самые подробные варианты отчетов и определили, что их можно отнести к трем группам: «Остатки финансов», «Анализ движения финансов», «План-фактный анализ». Исходя из того, что пользователь системы может не обладать знаниями и опытом бухгалтера, было принято решение о реализации задачи на оперативных, а не бухгалтерских объектах.
Существо же показателей, выводимых в отчетах, позволила спуститься на одну ступеньку вниз и определить структуру оперативных регистров. Показатели остатка, показатели движения (оборотов), показатели состояния были реализованы на регистрах остатков, регистрах оборотов и регистрах сведений – соответственно. Разрезы (группировки) информации в отчетах определили наборы измерений регистров, показатели – наборы ресурсов.
Конкретизация регистров и их измерений позволило сделать следующий шаг – перейти к регистрации событий, приводящих к изменению показателей учета, т.е. определила структуры документов конфигурации. В свою очередь, набор реквизитов документов позволили однозначно перейти к следующей ступеньке - определению структуры справочников. Используя принципы структурного программирования, мы смогли реализовать каркас решения всего за пару часов.
Единственное, что заставило задуматься – это реализация структурной схемы компании с использованием справочников. С одной стороны, структура должна быть иерархическая, с другой – хоть и с небольшой вероятностью, но она может изменяться. А «помнить» надо и старую структуру, и новую. Замечательным выходом из положения стало разделение структурной схемы компании на три справочника «Отделы», «Сотрудники», «Проекты» (проекты) с ведением истории иерархического подчинения на двух периодических регистрах сведений «ЗакреплениеСотрудников», «ЗакреплениеПроектов». Кроме обеспечения гибкости во времени, это структурное решение очень сильно облегчило впоследствии реализацию технологии быстрого заполнения документов. Для отнесения некоторого дохода или расхода к определенному проекту, определенному сотруднику и определенному отделу пользователю достаточно начать набирать название проекта в реквизите «Проект» и нажать « Enter ». Система сама завершит дело – или подставив конкретный проект из справочника, или предложив на выбор несколько созвучных элементов.
Программное же определение сотрудника–хозяина этого проекта, и отдела, к которому относиться в данный момент сотрудник, с подстановкой найденных значений в строку документа ничего сложного не представляет. К этому мы вернемся несколько позже.
При создании форм для данного проекта средствами «1С:Предприятия 8» душа просто пела потому, что их создавать… не надо. Это, конечно, шутка, … но с большой долей правды. Из своего опыта можем утверждать, что создавать формы в конфигураторе есть смысл в том случае, если пользователь нуждается в дополнительном сервисе. Так, для 26 объектов конфигурации, включая вспомогательные, было создано всего 10 форм. Все остальные строятся системой «на лету», при обращении пользователя к данному объекту. Более того, заметили, что эргономика и эстетика этих форм, построенных системой, зачастую даже выигрывают по сравнению с создаваемыми руками программиста.
Для обеспечения дополнительного сервиса в формах, понадобилось, например, организовать быстрый просмотр содержимого документов (таблиц приходов и расходов) непосредственно в форме журнала документов.
Интересно сравнить реализацию этого свойства в двух платформах 7.7 и 8. Сначала добавляем на диалог два табличных поля. После чего надо обеспечить их заполнение информацией при «скольжении» курсора в верхней таблице по строкам с документами. Опытные программисты наверняка знают, как решить подобную задачу для v 7.7, а главное, знают, чем за это придется «заплатить».
Для реализации того же свойства в «1С:Предприятии 8» все было сделано без программистских «финтов» и изощрений. Рассмотрим эту операцию пошагово, чтобы не быть голословным.
Шаг 1. Открываем свойства верхнего табличного поля.
Шаг 2. Выбираем среди двух десятков событий интересующее нас и нажимаем кнопочку «с лупой». Попадаем в обработчик этого события. Процедура принимает еще параметр «Элемент», смотрим в «отладчике», - что за контекст падает на этот параметр и понимаем, что - это контекст всего табличного поля. Прокручиваем список свойств данного объекта, смотрим, чем они заполнены:
Шаг 3. Видим, что свойство «ТекущаяСтрока» возвращает контекст документа активной строки. Именно это нам и нужно - заполнить данными этого документа элементы данной формы, т.е. нижние табличные поля.
Шаг 4. Начинаем писать текст процедуры с ЭлементыФормы, ставим точку, и… контекстная подсказка дает на выбор полный перечень свойств и действий, которые могут понадобиться:
То же самое происходит и после выбора очередного объекта в качестве свойства.
Подведем итоги первого опыта программирования на v 8. Текст процедуры заполнения нижних таблиц - это буквально два раза по две строчки, причем, и эти строчки написаны скорее синтаксис-подсказчиком, чем программистом. Вот что получилось в результате:
Мы намеренно подробно остановились на описании типичных действий программиста, при написании кода на v 8, чтобы показать: для более-менее уверенного программирования на новой платформе не требуется полугода или года наработки практического опыта в виде всевозможных приемчиков и финтов. Для первых внедрений будет достаточно активно использовать синтаксис-помощник, синтаксис-подсказку и отладчик. Достаточно просто прохождения какого-нибудь установочного курса, дальше все идет значительно легче.
Следующий момент, который пришлось реализовывать программно, – это определение и подстановка в строку документа сотрудника и отдела по введенному пользователем проекту. Поскольку это действие выполняется более чем для одного вида документа, было принято решение вынести процедуру в общий модуль:
Прелесть написания данного программного кода состояла в том, что вручную в данной процедуре набраны только две последние строчки и определение параметров. Формирование же и выполнение запроса было результатом действия шаблона запроса, а текст запроса получен в конструкторе запроса.
Безусловное проведение, т.е. проведение без каких-либо дополнительных расчетов, когда данные из документа непосредственно участвуют в заполнении записей регистров, выполняется конструктором движений. Это один из элементов механизма быстрой разработки приложений. В рассматриваемом проекте это относилось к движениям по регистру «Остатки денежных средств» и в большинстве случаев при проведении по регистру «ДвижениюФинансов». Наиболее «сложным» моментом была реализация распределения общефирменных расходов или расходов отделов на нижестоящие элементы структуры компании. В большинстве случаев точно известно, к какому проекту относиться те или иные затраты, но иногда возникают расходы, например, аренда офиса, которые «обременяют» все активные проекты одновременно.
Однако, если разносить такие затраты на все проекты «равномерно», получится не слишком адекватный управленческий результат — рентабельность только-только начинающего раскручиваться проекта будет, как правило, получаться очень низкой. А ведь начинающих полагается опекать и терпеливо взращивать. Потому было принято решение о введении «коэффициентов распределения» расходов, позволяющих гибко управлять этим процессом, причем, величины коэффициентов распределения могут меняться с течением времени. Для реализации таких временных изменений использовали регистры сведений. Основа дальнейшего решения была реализована в конструкторе запросов:
Одна таблица из вложенного запроса по закреплению сотрудников, два левых внешних соединения с таблицами, содержащими коэффициенты отделов и сотрудников, две группировки плюс общий итог. Отметим, что расчет величины произведения коэффициента сотрудника и коэффициента отдела производится непосредственно в момент указания выходных полей запроса. После выполнения запроса остается определить общий итог этой величины – это знаменатель пропорции, ну а числитель получается уже линейным перебором результирующей таблицы для каждого сотрудника каждого отдела. Пропорция распределения общих расходов – готова! Как и раньше, описание идеи и задачи и метода ее решения заняли больше времени, чем ее реализация.
Отчет «ОстаткиФинансов» весь, вплоть до последнего «винтика», построен конструктором выходных форм. Это результат реализации средств быстрой разработки приложений в новой платформе.
Программисту пришлось просто отвечать на вопросы конструктора. Все остальное - диалог, модуль, макет, работа с расшифровками в табличном документе, — система сделала сама. Единственное, что дописывали вручную, — это все поля группировки на макете свели в одну колонку для экономии места.
Отчет «Анализ Движения Финансов» — это самая красивая часть конфигурации. Формат статьи вряд ли позволит привести все возможные режимы его использования. Рассмотрим только два режима из всего разнообразия: "шахматку" с использованием группировки и диаграммы.
В данном отчете можно использовать более 20 видов диаграмм. На рисунке приведен один из них - «круговая объемная» для доходов одного из отделов по проектам. Рассмотрим этапы создания отчета более детально. Начнем с назначения отчета, как было определено в техническом задании:
«…В связи с использованием отчетов для решения различных аналитических задач (от планирования рентабельности до получения информационной базы для расчета с сотрудниками) – необходимо реализовать, прежде всего, требование универсальности. Должны присутствовать группы отчетов:
Отчеты должны позволять использовать фильтры по:
С подключением или отключением разворотов информации по группировкам:
Возможная периодичность:
Уверен, что специалисты по версии 7.7 оценят, сколько пришлось бы писать кода, чтобы реализовать такую функциональность «с нуля». В конфигурации на базе «1С:Предприятие 8» выполнили четыре шага.
Шаг 1. Создаем диалог, в котором Пользователь посредством табличных полей сможет управлять построителем отчета:
Шаг 2. Прописываем действия по нажатию на кнопку «Сформировать»
Шаг 3. Пишем процедуру ФормирЗапрос(), основа к
оторой - текст запроса:
Шаг 4. Обеспечиваем дополнительный сервис в области оформления. Например, если выбирается режим отчета «рентабельность», сразу убираем из настроек поля «доход» и «расход», если они есть, и добавляем поле «рентабельность», если его нет. На реализацию этих сервисных возможностей и ушло основное время написания отчета.
Хотелось бы описать опыт использования диаграммы. Уже на этапе тестирования выяснилось, что один из режимов отчета «Доходы и расходы одновременно» плохо отображается в диаграмме. Диаграмма построителя отчета настроена на один показатель, а в нашем случае требовалось выводить два.
Первое решение было, естественно, лобовым. Решили видоизменить текст запроса так, чтобы два показателя ретранслировались в один, но с дополнительной группировкой по виду движения. Операнд «Выбор» позволял это делать, но после этого «улучшения» стал «съезжать» другой режим работы отчета, за исправлением этого – еще что-то не понравилось…
И только, когда решился остановить этот «марш улучшений» и просто ввести в оборотный регистр еще один ресурс, все вернулось в исходное – лаконичное и красивое — состояние. Отсюда вывод: надо больше доверять структурным решениям, как бы ни хотелось перепробовать все программистские.
Ввод бюджета решили сделать без документа: из табличного поля обработки - напрямую в соответствующий регистр сведений.
Программно это выглядело так:
Ничего сверхъестественного. Отчет «План-Фактный анализ» опять же был получен конструктором выходных форм. На этом собственно, программистская работа была завершена.
Демонстрация системы заказчику и ее апробация показали, что система делает не только то, что прописано руками программиста. У нее масса разнообразных возможностей, не потребовавших для реализации написать ни строчки кода, но просто восхитивших заказчика. Честно говоря, не всегда находилось мужество сознаться, что все понравившиеся заказчику свойства были уже заложены в движке и не являются плодом нашего упорного труда. Из особенно приглянувшихся, на которые мы советуем обращать внимание при демонстрации, следующие:
Выше приведены только некоторые возможности, которые на текущий момент были востребованы пользователем. На самом деле в платформе их заложено гораздо больше. От некоторых пользователь даже пока отказался, что бы «глаза не разбегались».
Каждая работа чему-то учит, добавляет новые или подтверждает старые идеи. Это внедрение не стала исключением. Попробуем обобщить полученный опыт.
Большинство рутинных операций система готова взять на себя. Конечно, остается возможность все это программировать и вручную, но смысл этого занятия зачастую исчезает.
Облачные сервисы
