Как заставить разработки работать

Публикация № 507806 30.03.16

Анализ и управление - Анализ и проектирование ИТ-систем

Разработка Внедрение Обучение Функциональное тестирование Испытания Тестирование

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

Гладко было на бумаге, да забыли про овраги

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

Процесс проработки сценария испытаний можно представить в виде следующей диаграммы (для каждого бизнес-процесса прорабатывается свой сценарий):

 

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

Например, сценарий испытаний процесса отгрузки товара мог бы выглядеть так:

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

 

К сценарию предъявляются следующие требования:

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

 

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

Однако испытания это ещё не все. Что бы система заработала, и затем работала без перебоев, необходимо обучить пользователей, а для обучения необходимо наличие методического материала, без которого обучение превратиться в импровизированное шоу. Я бы выделил 3 категории методического материала, который необходим для обучения и дальнейшей работы пользователей: инструкции, сценарии и регламенты.

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

  1. Перейдите Торговля – Номенклатура, откроется справочник Номенклатура:

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

  1. Укажите наименование номенклатуры:

  1. Нажмите Записать и закрыть;

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

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

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

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

 

Пришёл клиент с накладными

  1. Найдите накладную в 1С по номеру (номер на бумажной накладной у клиента);
  2. Соберите заказ на складе;
  3. Отразите расходный ордер в 1С;
  4. Вручите товар клиенту;

 

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

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

Не мешай системе работать

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

  • Программная ошибка;
  • Логическая ошибка функционала;

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

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

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

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

Ошибки после доработок работающей системы зачастую проявляются при использовании следующей схемы внесения изменений:

 

 

К1 – это конфигурация базы, которую эксплуатирует заказчик. Буква С в скобках означает что она стабильная. Стабильная – это значит, что пользователи в ней работают и не испытывают никаких проблем, т.е. система решает поставленные задачи. В какой-то момент в конфигурацию разработчик вносит изменение (не важно, либо редактирует прямо в рабочей базе, либо путём сравнения объединения), в результате получается конфигурация К2, но, так как после внесения изменений функционал в базе никто не тестировал (так как это бы привело к остановке работы в базе на какое-то время до завершения отладки), то конфигурация получилась нестабильной. Причём, она будет нестабильной, даже если тестирование делалось где-то в базе разработки либо тестовой базе, ведь сам момент внесения изменений в конфигурацию – это потенциальная возможность что-либо сломать, причём в самом неожиданном месте. Это как если вы сдадите автомобиль на СТО для ремонта двигателя, а забрав его, спустя время обнаружите, что у него повреждена краска на заднем бампере. Лишь только внесение изменений путём полной загрузки конфигурации, которая выгружена из полностью протестированной базы, даст гарантию стабильности функционала рабочей базы. Однако, такое возможно только если изменения в систему вносит один разработчик. В нашем случае, Изменение 2 вносит второй разработчик, путём сравнения объединения, в результате получается конфигурация К3, еще более не стабильная, причем в ней могут оказаться испорчены изменения 1-го разработчика.

Так как конфигурация К3 оказалась нестабильной, в процессе эксплуатации будут выявляться проблемы, которые тут же в спешном порядке придётся исправлять. А внося исправления можно случайно ещё что-то сломать, поэтому процесс отладки может длиться несколько дней. Таким образом, только после внесения n исправлений в конфигурацию рабочей базы будет получена стабильная конфигурация. Все бы ничего, но не каждый заказчик терпелив.

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

Решением этой проблемы может стать функциональное и приемочное тестирование.

Функциональное тестирование

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

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

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

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

Все тесты стоит объединить в один реестр, и в дальнейшем, каждый раз прогонять их перед обновлением работающей системы. Ускорить процесс тестирования можно воспользовавшись специализированными инструментами, позволяющими его автоматизировать. Например, «1С:Сценарное тестирование 8», входящий в состав «1С:Корпоративный инструментальный пакет 8».

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

Для примера рассмотрим ситуацию:

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

Разработка была выполнена разработчиком, рабочая база была обновлена, было произведено внедрение. Пользователи начали использовать данную функцию.

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

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

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

Заполнение РТУ себестоимостью

  1. Добавляет номенклатуру Перчатки;
  2. Отражает поступление перчаток (Поступление товаров) в количестве 10 шт по цене 100 р;
  3. Отражает Реализацию перчаток (Реализация товаров) в количестве 5 шт, цену заполняет себестоимостью;

Контроль: цена перчаток автоматически установилась 10 р;

 

Этот тест добавляется в реестр функциональных тестов.

Затем, обновление конфигурации релизом от стороннего поставщика выполняется на тестовой базе, конфигурация в которую загружается из рабочей. Допустим тот же разработчик так же при обновлении взял форму документа РТУ из конфигурации поставщика. Теперь, после обновления производиться функциональное тестирование. Когда тестировщик дойдёт до теста Заполнение РТУ себестоимостью, он столкнётся с проблемой: невозможно произвести заполнение себестоимостью, так как эта команда отсутствует. Проблему он зафиксирует в протоколе тестирования, который будет предоставлен разработчику, который в свою очередь неспешно в общем порядке разберется с этой проблемой, восстановит команду и снова отдаст конфигурацию на тестирование.

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

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

Приемочное тестирование

Для примера рассмотрим следующую ситуацию (логическую ошибку):

В какой-то момент было требование заказчика, исходившее от менеджера по продажам: Необходимо иметь возможность вести справочник номенклатуры, а при поступлении указывать цену товара в рублях. В дальнейшем должна быть возможность просматривать цены на товары в виде отчета Анализ цен номенклатуры.

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

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

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

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

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

 

Тест 1:

  1. Администратор (А): Добавляет пользователя Менеджер по продажам (МП);
  2. Менеджер по продажам (МП): Создает номенклатуру Шапка-ушанка;
  3. МП: Отражает поступление номенклатуры:

Номенклатура

Цена

Количество

1

Шапка-ушанка

100

5

  1. МП: Формирует отчет Анализ цен номенклатуры
    Контроль: Эталонный отчет «Анализ цен номенклатуры 1.mxl»

 

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

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

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

 

Обобщенный процесс разработки функционала

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

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

Далее принимается решение разработать новый функционал. Для этого разворачивается новое хранилище Х2.0.7.0 путём копирования хранилища Х2.0.6.15С. В новом хранилище начинается разработка и разработчики фиксируют из своих баз с конфигурациями КР3 и КР4 изменения с новым функционалом и в какой-то момент получается конфигурация с новым функционалом Х2.0.7.1Н (Н – нестабильная). Так как конфигурация 2.0.7 нестабильна, начинается процесс тестирования, посредством выполнения всех функциональных и приемочных тестов. Так как были выявлены проблемы в ходе тестирования, конфигурация по-прежнему нестабильна. Эти проблемы исправляются и получаем конфигурацию Х2.0.7.2Н. Так продолжается до тех пор, пока в процессе тестирования не будет выявлено ни одной проблемы и не получим стабильную конфигурацию Х2.0.7.5С, на основании которой можно собрать поставку и предоставить клиентам очередной релиз.

Если в процессе разработки функционала в хранилище 2.0.7 в релизе 2.0.6 клиентами обнаруживаются критические ошибки, не выявленные в процессе тестирования, их исправление выполняют разработчики в базах с конфигурациями КР1 и КР2, полученными из хранилища Х2.0.6.15С. После исправления изменения фиксируются в хранилище и полученную конфигурацию Х2.0.6.16Н тестируют. Параллельно эти же исправления вносятся и в хранилище 2.0.7, чтобы эти критические ошибки не попали в релиз 2.0.7, а внутренняя документация пополняется тестами, направленными на их отлов. Так как ошибок в конфигурации Х2.0.6.16Н не было найдено, она признается стабильной и выпускается релиз Р2.0.6.16, который предоставляется клиентам.

Важно понимать, что:

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

 

Если, в процессе разработки функционала для релиза 2.0.7 возникла потребность ещё в каких-то функциях, то принимается решение начать разработку релиза 2.0.8, хранилище которого разворачивается путём копирования хранилища конфигурации в состоянии Х2.0.7.1Н. В этом случае, по завершении разработки в хранилище 2.0.7 изменения, которые были в него внесены начиная с состояния Х2.0.7.1Н должны быть перенесены в хранилище 2.0.8.

Итоги

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

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

 

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

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

 

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

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

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. weissfeuer 44 02.04.16 23:16 Сейчас в теме
А те, кто поставил плюсы, читали вообще публикацию? Или за красивые схемки поставили? Это же трэш, начиная с первого абзаца: "Условно внедрение можно разбить на два этапа: подготовка и пуск" WTF?!!

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

Хочешь научиться писать человеческим языком, вот тебе хорошая ссылка http://maximilyahov.ru/hello/
IgorS; Award; mr.lynx; dabu-dabu; so-quest; Nelli_A86; pavlov_dv; EliasShy; dj_serega; ZOMI; Messenger Unchained; +11 Ответить
2. liurn 57 03.04.16 10:28 Сейчас в теме
(1) weissfeuer, ощущение, что комментарий писал закоренелый анархист и брюзга: обгадил все фигурально и ничего по существу. Если хочешь поласкать свой нежный литературный слух - почитай классиков. Здесь авторские публикации не для конкурса красноречия, языком кто как умеет, а не как нравится именно тебе.
jerry_maguire; +1 1 Ответить
9. weissfeuer 44 03.04.16 15:17 Сейчас в теме
(2) поржал)))). По существу - у меня все замечания конкретные, нет ничего фигурального. И даже "что делать" написано - не поленитесь прочитать статью по ссылке.
10. liurn 57 03.04.16 19:01 Сейчас в теме
(9) weissfeuer, если есть что возразить по предложенным способам решения обозначенных проблем - изложи, может вместе поржем, и это будет по существу. Иначе не вижу смысла продолжать наивный спор у кого фразы витиеватее а у кого замечания фигуральнее. Все равно каждый при своём останется.
Что касается того что мой стиль изложения пришёлся кому то не по душе - это я понял. Не нужно одно и то же писать по несколько раз. Но всем не угодишь и о стилях не спорят. И это не по существу.
3. пользователь 03.04.16 11:40
Сообщение было скрыто модератором.
...
5. liurn 57 03.04.16 13:36 Сейчас в теме
(3) liana-banana, так и до стольба можно докопаться, что плохо стоит
7. Messenger Unchained 03.04.16 13:49 Сейчас в теме
(5), (6) - оу, у нас появился еще один Лустин, который "вставляет пасхальные закладки/опечатки в публичных блогозаписях" чтобы что-то понять и доказать?
8. liurn 57 03.04.16 14:23 Сейчас в теме
(7) Messenger Unchained, понять свои ошибки я не прочь, но доказывать что-то кому-то - дело не благодарное
11. Messenger Unchained 03.04.16 20:51 Сейчас в теме
(8) ты прав. Заканчиваю доказывать.
4. Messenger Unchained 03.04.16 11:50 Сейчас в теме
2) в (1) написана совершенная правда.
Если бы публикация была техническая, то за идею и ее разворачивание можно многое и простить.
Но суть твоей публикации сводится к очередному обмусоливанию каких-то сакральных тайн.

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

Так и видится вскипевший пользователь, убеждающийся в том, что товары местонаходятся
6. liurn 57 03.04.16 13:43 Сейчас в теме
(4) Messenger Unchained, не буду спорить, что тот кто не в теме увидит здесь сокральную тайну.
А что не так с местонахождением?
12. so-quest 140 04.04.16 14:03 Сейчас в теме
Два раза прочитал, но так и не понял - что рекламируют? У Лехи хоть названия продуктов и ссылки на его разработки и сообщество. А тут кроме менеджерского словоблудия - ничего...
И "это" рекомендуют эксперты.
16. pro-rok 298 06.04.16 08:27 Сейчас в теме
(12) so-quest, тут не рекламируют, а делятся опытом и подходами.
По поводу стиля, хочу сказать, ЧТО ВЫ ПРИДИРАЕТЕСЬ. Человек решил опытом поделиться, а вам витиеватые фразы не понравилось, согласен что читать сложно, но это не главное.
Относительно статьи, идея хорошая , хотя и не новая. на мой взгляд, было бы очень полезно если бы данная статья содержала в себе краткий кейс.
13. liurn 57 04.04.16 22:44 Сейчас в теме
Под натиском критики отредактировал анонс
15. Messenger Unchained 04.04.16 23:49 Сейчас в теме
(13) отлично! Специалисты первой линии поддержки на крупном федеральном предприятии, где как раз внедряют 1С, уже оценили!
14. mulla1979 9 04.04.16 23:44 Сейчас в теме
А что, нормальная статья, только букв много...Я бы разделил статью на 2 части (до "не мешай системе работать" и остальное). А по смыслу все правильно написано! Я в данный момент работаю специалистом первой линии поддержки на крупном федеральном предприятии, где как раз внедряют 1С, и все эти проблемы прямо как на ладони! Причем в комплексе... Поэтому, в качестве ликбеза для начинающих внедренцев и разработчиков эта статья будет в точку! Автору плюс!
17. МимохожийОднако 140 06.04.16 08:47 Сейчас в теме
Статья хороша как реферат для преподавателя, но для практики малопригодна.
18. AlexWhite 196 06.04.16 09:02 Сейчас в теме
необходимо разработать тест для каждой функции и включить его в реестр тестов
- на чем разрабатывается функциональный тест, кто, в какой момент его должен разработать и что из себя представляет реестр тестов?
22. liurn 57 06.04.16 22:19 Сейчас в теме
(18) AlexWhite, описать формально текстом может и разработчик, если нет тестировщика. Разрабатывается когда реализована очередная функция, главное - до того как начнётся тестирование. Реестр тестов - например текстовый документ, где каждый раздел - это тест. Это уже конкретный инструмент, кому что нравиться, не буду навязывать своё мнение. Если использовать 1с:сценарное тестирование - сама база и будет реестром. Не стал вдаваться в такие подробности, так как в этом случае меня вообще местные критики линчевали бы )
19. AlexWhite 196 06.04.16 09:28 Сейчас в теме
По "обобщенной схеме разработки" появились вопросы - не понятно, Х2.0.6.16Н (нестабильная), после тестирования превращается в стабильную Ч2.0.6.16С, но потом, почему-то, попадает в рабочую Р2.0.6.15 или это ошибка на схеме?
Кто, каким способом, следит, сколько ветвлений произошло, какая ветвь, в какой момент годится для внедрения в рабочую конфигурацию, каким образом рабочие конфигурации связаны с конкретными ветвями разработки и тестирования?
23. liurn 57 06.04.16 22:23 Сейчас в теме
(19) AlexWhite, да, это опечатка. Должно быть Р2.0.6.16. Спасибо, исправлю как нибудь.
20. Yashazz 4506 06.04.16 17:13 Сейчас в теме
Очередные рассуждизмы ни о чём. Когда уже все высокоумные господа-в-галстуках, трущиеся вокруг IT, поймут, что единственное - именно единственное, - что является залогом успешного
внедрения - это административный ресурс. Скажут жрать кактус - будут колоться и жрать. Не скажут - вы их ничем не соблазните, хоть наизнанку вывернись.

А то всё схемы, графики, заумь-то какая, простихосспади.
21. liurn 57 06.04.16 22:12 Сейчас в теме
(20) Yashazz, вы меня с кем то путаете. Не будь я жертвой приказов жрать кактусы - никогда бы не занимался тем чем занимаюсь.
24. liurn 57 06.04.16 22:29 Сейчас в теме
Отредактировал статью, уменьшил количество букв. Надеюсь сейчас она будет меньше раздражать и проще читаться. Спасибо за комментарии, в том числе и отрицательные.
А для любителей рекламы - добавил, рекламу продуктов 1С.
25. Sairys 16.04.16 12:24 Сейчас в теме
Небольшая ошибка в тексте "Собственный и заимствованный опыт позволили выработать подходы к решению некоторых их них."
Оставьте свое сообщение

См. также

Бесплатный сыр в мышеловке, или Как бизнес-аналитику прокачать себя самостоятельно

Мотивация, лидерство и личная эффективность Анализ и проектирование ИТ-систем Бесплатно (free)

Приняли решение стать аналитиком 1С, но не знаете, как? Попробуем сконструировать курс под свой уровень развития так, чтобы все нужные нам материалы были максимально доступны и требовали минимальных финансовых вложений. Руководитель отдела сопровождения финансового учета компании САМОКАТ Анастасия Штей на конференции Infostart Event 2022 Saint Petersburg рассказала, как искать и систематизировать нужную информацию об ИТ-анализе, чтобы прокачать свой уровень знаний аналитика 1С самостоятельно.

17.05.2023    890    ashtey    1    

5

Бухгалтерский и Управленческий учеты - антагонисты, симбионты или альтернативы?

Анализ и проектирование ИТ-систем Россия Бухгалтерский учет Управленческий учет Бесплатно (free)

Автор за долгие годы так и не получил внятного представления о субстанции под названием "управленческий учет". Статья - попытка порассуждать на эту тему и получить советы и отзывы коллег.

25.04.2023    710    DemetrKlim    22    

8

Радио "Аналитик", выпуск 15. О текстах в интерфейсах с Александром Марфициным

Анализ и проектирование ИТ-систем Бесплатно (free)

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

03.04.2023    294    Radio_Analyst    0    

3

Кого найти? Кому отдаться? (если вы решили стать 1С аналитиком). Часть 2

Анализ и проектирование ИТ-систем Россия Бесплатно (free)

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

20.03.2023    1282    Senator_I    4    

7

Радио "Аналитик", выпуск 14. О когнитивных искажениях, сервисе UX CORE и проекте KeepSimple c Вольфом Алексаняном

Анализ и проектирование ИТ-систем Бесплатно (free)

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

20.03.2023    259    Radio_Analyst    0    

3

Дизайн-мышление как инструмент предпроектной аналитики

Анализ и проектирование ИТ-систем Бесплатно (free)

Алексей Таченков на Infostart Event 2021 Moscow Premiere поделился своим опытом внедрения дизайн-мышления в процесс предпроектного исследования, а также рассказал об инструментах для анализа и улучшения пользовательского опыта. Методика будет интересна для разработчиков, которые хотят создавать качественные продукты и удовлетворять потребности пользователей.

10.03.2023    597    tachenkov    0    

5

Радио "Аналитик", выпуск 13. О книге Карла Вигерса "Разработка требований к программному обеспечению" с Александром Байкиным

Анализ и проектирование ИТ-систем Бесплатно (free)

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

06.03.2023    2131    Radio_Analyst    0    

5

Куда пойти? Куда податься? (если вы решили стать 1С аналитиком). Часть 1

Анализ и проектирование ИТ-систем Бесплатно (free)

В статье рассматривается путь в профессию аналитика 1С. В первой части статьи рассмотрю, какие есть направления для обучения. Рассмотрим специализацию аналитиков и как выбрать нужную.

02.03.2023    1635    Senator_I    13    

6

Бизнес-аналитик 1С: универсальный солдат или кто?

Анализ и проектирование ИТ-систем Внедрение ИТ-системы Бесплатно (free)

Анастасия Штей рассказала на конференции Infostart Event 2021 Post-Apocalypse, как вырасти до бизнес-аналитика, и через какие испытания придется пройти. В своем докладе она рассуждает, почему эта профессия еще не до конца сформирована на российском рынке, и какие скилы должен качать бизнес-аналитик, чтобы стать профессионалом.

01.03.2023    1285    ashtey    0    

7

Гармония порядка и гибкости

Бюджетирование и планирование Анализ и проектирование ИТ-систем Бесплатно (free)

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

15.02.2023    620    alex_safin    1    

7

Радио "Аналитик", выпуск 11. О создании продуктов с Сергеем Колосковым

Анализ и проектирование ИТ-систем Бесплатно (free)

В одиннадцатом выпуске подкаста Радио “Аналитик” обсудили, как найти актуальную проблему для создания продукта, как проверить идею продукта на востребованность и как сделать продукт привлекательным для потенциальной аудитории.

06.02.2023    344    Radio_Analyst    0    

3

Радио "Аналитик", выпуск 9. О ванильном мороженом и обучении аналитиков 1С с Анастасией Штей

Анализ и проектирование ИТ-систем Бесплатно (free)

В девятом выпуске подкаста Радио “Аналитик” обсудили, какое обучение доступно будущим аналитикам 1С сейчас, с какими трудностями могут столкнуться выпускники курсов и что ожидают от аналитиков работодатели.

13.01.2023    467    Radio_Analyst    0    

3

Пример автоматизированного управления публикацией списка баз

Анализ и проектирование ИТ-систем Администрирование СУБД Бесплатно (free)

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

29.11.2022    943    Elaks    3    

9

Мобильные приложения 1С: зачем они бизнесу? Обзор + 7 идей применения

Мобильная разработка Анализ и проектирование ИТ-систем Бесплатно (free)

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

31.10.2022    1407    ystetsenko    1    

2

Простой пример частного технического задания (ЧТЗ) для 1С-ника

Анализ и проектирование ИТ-систем Бесплатно (free)

В статье расскажем о том, как происходит разработка структуры технического задания. Покажем пример технического задания в 1С.

27.10.2022    6199    Koder_Line    3    

6

Аналитик 1С: так ли он нужен?

Анализ и проектирование ИТ-систем Управление командой Внедрение ИТ-системы Россия Бесплатно (free)

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

13.10.2022    3291    ystetsenko    16    

5

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Анализ и проектирование ИТ-систем Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    9895    Evil Beaver    17    

99

Дизайн-мышление в заказной разработке

Анализ и проектирование ИТ-систем Бесплатно (free)

Метод дизайн-мышления смещает приоритеты разработки на потребности пользователя. Но как понять, что пользователь хочет и учесть его подразумеваемые требования? О том, как с помощью эмпатии к пользователю и визуализации идей сделать удобный для заказчика продукт, в докладе на Infostart Event 2021 Moscow Premiere рассказала Мария Серёгина.

30.06.2022    2453    SerjoginaMaria    15    

8

Автоматизация vs оптимизация

Анализ и проектирование ИТ-систем Внедрение ИТ-системы Бесплатно (free)

Анализ и оптимизация бизнес-процессов становятся все более востребованными в проектах автоматизации, а с массовым переходом с 1С: УПП на 1С:ERP эта задача станет еще более актуальной. О том, как собрать полную картину реальных потребностей вашего заказчика, исходя из логики его бизнес-процессов, на конференции Infostart Event 2021 Moscow Premiere рассказала Елена Иванова.

27.06.2022    2753    e_ivanova    0    

11

Скальпель, зажим, … пластырь, валерьянка. Мы закончили..: инструменты работы бизнес-аналитика

Анализ и проектирование ИТ-систем Бесплатно (free)

Считается, что аналитику для работы на проекте достаточно уметь строить бизнес-процессы в одной-двух популярных нотациях. Но это не так, потому что работа аналитика гораздо разнообразнее и не ограничивается рисованием схем. О том, какие инструменты пригодятся аналитику и помогут ему сделать свою работу комфортной и удобной, на конференции Infostart Event 2021 Moscow Premiere рассказала руководитель отдела сопровождения финансового учета компании «Самокат» Анастасия Штей.

23.06.2022    4934    ashtey    0    

38

Эмпатия и системный подход в сборе требований и составлении ТЗ

Анализ и проектирование ИТ-систем Внедрение ИТ-системы Бесплатно (free)

Начальник отдела внедрения и сопровождения информационных систем в торговой сети «Командор» Елена Качаева выступила на митапе «Сбор требований и составление ТЗ». Елена рассказала, как разобраться в особенностях клиента, как найти с заказчиком общий язык и составить корректное ТЗ, которое в дальнейшем будет легко реализовать и сдать.

10.06.2022    2283    kacelena    2    

14

Аналитика и BI. Белые пятна рынка и тренды, которые нельзя игнорировать

Анализ и проектирование ИТ-систем Консолидация данных Бесплатно (free)

Мир вычислений бурно развивается, и потребность анализировать «большие данные» уже плотно вошла в жизнь любой, даже маленькой компании. О том, какие исторические предпосылки привели к текущей ситуации на рынке BI-систем, и какие перспективы у этого развития, на митапе «Бизнес-анализ по данным базы 1С» рассказали представители компании «Консон» Евгений Скребанов и Иван Мищенко.

08.06.2022    1924    imischenko    0    

2

SAFe Epic (Эпик)

Анализ и проектирование ИТ-систем Бесплатно (free)

Перевод https://www.scaledagileframework.com/epic/, с переводом сопутствующих терминов, для понимания основного термина и варианта его использования.

06.06.2022    1435    malikov_pro    0    

4

ТЗ как обязательный атрибут в автоматизации. Реальные кейсы из 16-ти летнего опыта

Анализ и проектирование ИТ-систем Бесплатно (free)

Техническое задание – документ, который многим кажется слишком дорогим удовольствием. Руководитель консалтингового направления ГК СофтБаланс Клавдия Макарова объяснила, почему нельзя на него смотреть только с этой точки зрения, и какую пользу он приносит команде и заказчику.

01.06.2022    2465    user1551153    0    

7

Путь покупателя интернет-магазина (Customer Journey) с использованием УФМТП

Анализ и проектирование ИТ-систем Управленческий учет Бесплатно (free)

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

12.05.2022    1495    raiml    2    

5

Универсальная функциональная модель торгового предприятия в нотации IDEF0

Анализ и проектирование ИТ-систем Управленческий учет Бесплатно (free)

Из чего состоит предприятие? Какие функции основные, а какие нет? В данной статье вы найдете ответ на этот и другие вопросы. Модель, построенная на основе опыта бизнес-консультанта с использованием нотации IDEF0.

12.05.2022    3912    raiml    4    

7

Современные СЭД: курс на упрощенчество и подмена понятий

Документооборот и делопроизводство (СЭД) Анализ и проектирование ИТ-систем Внедрение ИТ-системы Управленческий учет Бесплатно (free)

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

12.05.2022    812    user1214797    5    

2

Business Objective Model или Модель бизнес-целей - где, зачем и как применять?

Анализ и проектирование ИТ-систем Бесплатно (free)

Модель бизнес-целей или Business Objective Model (далее BOM) - техника, которая захватила моё сердце и разум с первого взгляда. Простая и наглядная, она помогает избежать того, от чего так часто возникает недопонимание между бизнесом и теми, кто его автоматизирует.

23.03.2022    2555    SerjoginaMaria    18    

19

Power BI дешево или очень дорого?

Консолидация данных Анализ и проектирование ИТ-систем Бесплатно (free)

На онлайн митапе «Бизнес-анализ по данным базы 1С. Интеграция c платформами BI» выступил Петр Базелюк, CTO компании Digital Business. Петр рассказал, как запустить систему аналитики для полноценной цифровизации всего бизнеса, сравнил возможности подписок Free, Pro и Premium и подсказал возможные пути минимизации затрат.

18.02.2022    4330    pbazeliuk    3    

11

Какие риски и ответственность берет на себя бизнес-аналитик

Анализ и проектирование ИТ-систем Бесплатно (free)

Профессия бизнес-аналитика хотя и интересная, но полна неопределенности. Чем должен заниматься этот специалист, какими навыками обладать, за что отвечать? На эти вопросы попытался ответить исполнительный директор Инфостарта Александр Чавалах.

16.02.2022    4380    chavalah    8    

18

Как мы подружили "1С:Аналитику" и "Финансист". Практический опыт

Консолидация данных Внедрение ИТ-системы Анализ и проектирование ИТ-систем Бесплатно (free)

«1С:Аналитика» – достаточно молодой инструмент от фирмы «1С». О том, как его настроить и запустить для отображения консолидированных данных из различных баз, на митапе «Бизнес-анализ по данным базы 1С. Интеграция с платформами BI» рассказала Ирина Богданова – ведущий разработчик тиражного решения «Финансист» в компании WiseAdvice.

11.02.2022    4316    bogira    2    

8

Не надо делать мне как лучше, оставьте мне как хорошо

Анализ и проектирование ИТ-систем 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Даже самое продуманное решение может потерпеть фиаско при внедрении, если пользователи не увидят в нем пользу.

08.02.2022    3598    SerjoginaMaria    37    

19

42 или главный вопрос по бизнес-процессам

Анализ и проектирование ИТ-систем Бесплатно (free)

Приветствую вас, уважаемые коллеги! Меня зовут Анастасия Штей, я – бизнес-аналитик 1С. Именно так я начинала свои доклады на INFOSTART EVENT 2021 Post-Apocalypse и INFOSTART EVENT 2021 Moscow Premiere. Мне очень близка тема бизнес-анализа, изучения подходов и практик моделирования бизнес-процессов и компетенции бизнес-аналитика. И сейчас я запускаю на Инфостарт серию статей, а уже скоро и курс, посвященный основам моделирования и анализа бизнес-процессов.

07.02.2022    7264    ashtey    20    

25

Документальное оформление бизнес-процессов в проектах по автоматизации

Анализ и проектирование ИТ-систем Управление проектом Внедрение ИТ-системы Бесплатно (free)

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

02.02.2022    9049    denisgalimoff    3    

23

Как бизнес-аналитик может повысить эффективность и прибыльность разработчиков

Управление ИТ-подразделением Анализ и проектирование ИТ-систем Бесплатно (free)

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

31.01.2022    2192    drmaxart    2    

8

Матрица компетенций аналитика 1С

Мотивация, лидерство и личная эффективность Анализ и проектирование ИТ-систем Бесплатно (free)

Тема мотивации сотрудников – одна из центральных в любой организации. Но, как и за что премировать работников, определиться сложно. В компании ФТО решили, что нужно сформировать матрицу компетенций, присвоить каждой определенное количество баллов, и уже на основании такой независимой оценки распределять премиальные. Подробнее о системе рассказала руководитель аналитиков 1С проектного отдела компании ФТО Анна Бирюкова.

28.01.2022    5024    abir    20    

19

Экспресс-обследование и реинжиниринг бизнес-процессов

Внедрение ИТ-системы Управление проектом Анализ и проектирование ИТ-систем Бесплатно (free)

Проведение обследования – это первый этап работы на проекте. От того, как этот этап пройдет, и какие результаты будут получены, будет зависеть дальнейший исход вообще всего проекта. О проведении обследования предприятия для целей управленческого учета на основе МСФО рассказал Генеральный директор ООО «Рэй Консалтинг» Николай Шилкин.

26.01.2022    3324    RayCon    1    

16

Бизнес-аналитики 1С: спрос есть, но кто они?

Управление ИТ-подразделением Внедрение ИТ-системы Анализ и проектирование ИТ-систем Бесплатно (free)

Каждый понимает по-своему, кто такой бизнес-аналитик и чем он занимается. Руководитель компании CORS Consulting Илья Отькало постарался ответить на вопросы, что должен знать такой специалист, какие знания и навыки ему пригодятся в работе.

24.01.2022    8081    otkalo    0    

19

Роль и задачи аналитика в проектной команде при внедрении 1С

Управление командой Внедрение ИТ-системы Анализ и проектирование ИТ-систем Бесплатно (free)

Типовые продукты фирмы «1С» становятся все более гибкими, и функция разработки или изменения для них очень часто вообще не требуется или требуется точечно, поэтому для подобных проектов появился отдельный специалист – аналитик 1С. Какие у него задачи, и чем он отличается от системного аналитика и бизнес-аналитика, рассказал руководитель отдела экспертизы компании «Первый БИТ» Денис Галимов.

19.01.2022    11582    denisgalimoff    8    

21