Инструкция по работе с новым программным продуктом, но также общие принципы работы подразделения, должностная инструкция специалиста и т д

Документацию нужно готовить во время тестовой эксплуатации

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

Тестирование интеграций

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

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

Оптимальное решение – это собрать всех людей в одном помещении, и проводить совместное комплексное тестирование.

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

Еще один пример. Интегрируется 1С и Zoho CRM. При этом в Zoho создается контакт, в 1С – контактное лицо. Один из менеджеров по продажам создает карточку клиента в Zoho, другой – работает в среде 1С. На основе данных, полученных из Zoho, менеджер в 1С создает контактное лицо и партнера.

Если схема работы компании такова, что оба менеджера будут работать и в Zoho, и в 1С, то во время тестирования имеет смысл менять их местами.

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

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

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