Какие действия нужно предпринять программисту или системному администратору для того, чтобы организовать переход на новую учетную программу.
Вам поставили задачу перейти на новую программу? И сохранить при этом все накопленные данные? Рассказываем как сделать это правильно.
Специалисты компании «Открытые Системы» имеют большой опыт перехода из программ для расчета зарплаты фирмы «Камин» в «1С». Мы выполняем переносы сами и помогаем переходить своим заказчиками с 2007 года. За это время у нас накопился большой массив как очень удачных примеров, так и тех, где пользователям пришлось столкнуться с трудностями из-за неправильно организованного процесса. На примере такого перехода мы и разберем все этапы процесса.
Наиболее частые причины проблем
80% вопросов, возникающих после перехода на новую программу, связано со следующими причинами:
- Перенос данных, настройку, сверку выполнял программист или системный администратор. Другие сотрудники (руководители направлений, бухгалтеры, кадровики и др.) в процессе переноса не участвовали («некогда», «много работы», «ты и так знаешь как мы работаем»).
- Сразу же после переноса начали вести учет в новой программе.
Претензии в обоих случаях, как правило, однотипны — «программа сырая», «не подтягиваются данные», «все приходится делать руками», «что ты за программист».
Перенос данных — это всегда проект! И поэтому подходить к нему нужно так же, как и к любому другому проекту — планировать этапы, контролировать их выполнение и результаты.
Чтобы сохранить нормальную рабочую атмосферу и здоровье, начинаем правильно готовиться. Итак, с чего же лучше начать.
Ну ладно, понеслась душа в АД
ЦитатаВиктор Дмитриенко пишет:
У нас сейчас цель.
Извините, но мне кажется у вас первая цель _Должна_быть_ обеспечить нормальную работу текущих клиентов. стабильная версия на сегодня считается сборкой CAD 5997
ей уже больше года, кто-то из моих коллег позвонил вам в связи с некоторыми проблемами, вы сказали мол чего это вы дровами старыми пользуетесь, ставьте новую версию (IndorCAD 6. 6053) в ней всё залипись. хорошо, поставили, кад ещё работает но дро. при открытии старых файлов возникли проблемы, при сохранении вновь созданных файлов возникают проблемы. Вопрос «как работать теперь дальше?»
проблему известную вам, вы не решаете уже больше 2х месяцев внося тем самым сложности в работу ваших клиентов, которых вы так сильно уважаете.
Обеспечьте хотя бы работу более старых версий. ГДЕ эта седьмая версия? вы её ещё на конференции обещали, на сайте всех завтраками кормите. при этом в старой работать невозможно. и тут вы говорите
«нам по фигу дорогие наши пользователи, за то, что вы купили у нас продукт и он не работает! и мы знаем это и не хотим исправлять его глюки, потому, что мы разрабатываем новую версию, а в старой куче. мы копаться не хотим, когда будет новая версия мы не знаем. »
Вас никто не просит новой функциональности, вас просят поправить существующую и я уверен, что там не тысячи строк кода править. иначе я усомнюсь ещё в вашей компетенции как разработчиков.
ЦитатаАлександр Перфильев пишет:
А критиковать путь M$ легко и весело. Труднее самому пройти хотя бы жалким подобием этого пути.
жизнь покажет, кто каким путём пройдёт и чего добьётся. , но историю учитывать и забывать не стоит. , а ещё есть очень поучительная история корпорации IBM, которая в силу недалёкости менеджеров по стратегии сделала упор не на текущих клиентов, и не на развивающийся рынок декстопов.
итог мы знаем — появилась история M$ которая подхватила волну.
Спасибо за исчерпывающие ответы, ваше отношение к пользователям мне ясно.
PS да и спасибо за годы приобретённой технической поддержки, при которой приходиться убалтывать вас поправить ВАШИ ошибки в ВАШЕМ софте.
PPS а теперь представьте, что ваши потенциальные клиенты читают данный форум. и видят ваше отношение к клиентам.
PPPS Я работаю уже добрых 2 года с вашим софтом, и пока ни одно моё обращение в суппорт на тему ошибок в вашем «продукте» я не получил адекватного ответа в виде исправления данной проблемы.
Изменено: Odmin4eg — 20. 2008 14:18:16
Проблемы перехода на современное программное обеспечение
Microsoft уже давно нарисовал мрачную картину для клиентов, которые по-прежнему пользуются Windows XP и Office 2003 после того, как поддержка старой операционной системы и пакета программ закончилась. Поддержка прекратилась специально чтобы способствовать переходу пользователей но новое поколение программного обеспечения. Microsoft подтвердила, что потребители и предприятия, которые пользуются старыми продуктами, после прекращения поддержки будут сталкиваться с серьезными рисками безопасности и не смогут воспользоваться преимуществами современных разработок. Компания предлагает клиентам установить Windows версии 8. 1 и воспользоваться преимуществами Office 365. ПК под управлением Windows XP не имеет аппаратных возможностей для запуска новой операционной системы. Windows microsoft office нуждается в последних версиях программного обеспечения, которое может полноценно работать только на производительном компьютереWindows 8 и ее обновления подверглись потоку критики за их оптимизированный под сенсорные панели интерфейс и ряд серьезных ошибок. Microsoft, конечно же, исправил все свои проблемы с помощью ряда обновлений, а уже в версии операционной системы под номером 10 сумел полностью устранить все проблемы. Наиболее пессимистично настроенные критики сравнивали Windows 8 с Windows Vista, выпущенной в 2007 году. Но сегодня все более радужно, поскольку все баги были успешно локализованы. Так что не стоит отказываться от преимуществ современного программного обеспечения.
При переходе на новую версию операционной системы неизбежно возникает проблема совместимости приложений, которая должна быть решена в ходе обслуживания компьютеров.
Проблема совместимости чаще всего возникает, когда приложение некорректно обращается к функциям операционной системы.
Как правило, ведущие производители программного обеспечения стараются своевременно выпускать новые версии программных продуктов, совместимые с актуальными операционными системами, но нередко предприятия для решения некоторых специфических задач вынуждены использовать ПО, совместимость которого с новой версией операционной системы находится под вопросом.
С учетом возможных проблем совместимости используемых приложений и новой версии операционной системы рекомендуется в обязательном порядке включить в подготовку к обновлению ОС на компьютерах предприятия следующие этапы:
· обязательная проверка используемого ПО на совместимость с новой операционной системой и сбор информации о выявленных в процессе этого тестирования проблемах
· Анализ приложений, у которых выявлены проблемы совместимости. В процессе этого анализа нужно выяснить, насколько необходимы предприятию данные приложения, выпущены ли для них новые версии, в которых решена проблема совместимости, и в случае отсутствия таких версий — поиск инструментов для решения проблем совместимости
· тестирование инструментария для решения проблем совместимости, желательно не слишком усложняющего обслуживание компьютеров.
Тестирование на совместимость позволяет проверить приложение в различных браузерах, на разных ОС, с различным программным обеспечением и аппаратными средствами.
Знаете ли вы, что 10% пользователей используют нестандартные браузеры?
Вы знаете, как выглядит ваш сайт в этих браузерах? И работает ли он во всех этих браузерах? Не очень то бы хотелось потерять 10% потенциальных клиентов.
Во время тестирования на совместимость команда тестировщиков проверяет, насколько хорошо приложение может работать с различными типами аппаратных технологий, драйверами и операционными системами.
Инсталляционное тестирование (installation testing)
В процессе инсталляционного тестирования проверяется корректность установки и удаления программного продукта в среде, максимально приближенной к эксплутационной. Об этом аспекте корректной работы программного обеспечения очень часто просто забывают (и напрасно). Правильно выполненная установка программы — необходимое условие её корректной дальнейшей работы. Проверка правильности установки должна быть обязательным элементом проекта по тестированию любого продукта. Если программу невозможно корректно установить, и при этом что-то не будет работать или будет работать неправильно, работа по тестированию самого программного тестирования бессмысленна. Почему? Потому что заказчику не нужен продукт, который даже невозможно установить. Если пользователь уже на этапе установки сталкивается с проблемами в разработанном программном продукте, что он подумает о самом программном продукте? Будет ли он связываться с такой фирмой-разработчиком?
Регрессионное тестирование (regression testing)
Повторное выполнение тестов для проверки того, что изменения, внесённые в программу в результате разработки новой или изменения существующей функциональности, устранения ошибок, не повлияли на функциональность, которая не изменялась (т. текущая версия ведёт себя идентично предыдущей, за исключением измененных областей).
Тестирование новой функциональности (new feature testing)
В данном виде тестирования акцент делается на тестировании новой функциональности, появившейся в конкретном выпуске (build) программного продукта.
Конфигурационное тестирование (configuration testing)
С помощью конфигурационных тестов проверяется совместимость продукта с различным программным (software) и аппаратным (hardware) обеспечением. Как правило, программный продукт делается с тем расчётом, чтобы он сразу работал в максимально разнообразной внешней среде. Если же речь идёт о «коробочном продукте», то фактор совместимости приобретает ещё более важное значение. Для того, чтобы выяснить реакцию продукта на окружение и соседство с другим программным обеспечением, и проводят данные тесты.
Тестирование совместимости (compatibility testing)
Тестирование совместимости помогает убедиться в функциональных возможностях и надёжности работы продукта в поддерживаемых браузерах (если речь идет о Web-приложениях) и операционных системах. Также может проверяться работоспособность продукта при использовании различных аппаратных платформ.
Тестирование удобства эксплуатации (usability testing)
Тестирование интерфейса человек/машина производится в отношении таких моментов как внешний вид пользовательского интерфейса, удобство навигации (преимущественно для Web-сайтов). Практичность и удобство использования – очень важные характеристики программного продукта. Например, программа может вполне соответствовать всем предъявляемым к ней требованиям с точки зрения функциональности. Но функции реализованы неудобно: некоторые шаги приходится повторять много раз, тогда как по логике достаточно выполнить однажды; расположение элементов интерфейса нелогично, программа быстро вызывает утомление и т. Для выявления такого рода недочётов и применяют тесты на удобство использования. Часто эта группа тестов относится к категории некритичных, но когда речь идёт, например, о рыночном готовом продукте, пренебрегать удобством эксплуатации весьма опасно.
5 дек 2018
Смена версии программного обеспечения несёт в себе как потенциальные выгоды, так и определённые риски. Рекомендации экспертов MERLION Engineering на примере перехода на новую версию СУБД.
Процесс обновления системного ПО – необходимость для любого развивающегося бизнеса, связанная не только с модернизацией ИТ-инфраструктуры, но и с определенными рисками. Последние необходимо грамотно учитывать и снижать. Как это сделать можно понять на примере перехода на новую версию популярной СУБД Microsoft.
Переход на новую версию SQL Server (2008 -> 2017)
Смена версии программного обеспечения несёт в себе как потенциальные выгоды, так и определённые риски.
Если на конкретном предприятии СУБД решает все возлагаемые на неё задачи достаточно хорошо, то ценность потенциальных выгод снижается, а риски всё ещё остаются актуальными. В этом случае обновление СУБД может откладываться до поры. Однако, неизбежно наступает момент, когда используемая версия достигает конца жизненного цикла и снимается с поддержки производителя. В этом случае переход на новую версию становится обязательным для предприятия, ценящего стабильность и безопасность своей информационной инфраструктуры. Тем не менее, за время, пока обновление откладывалось, расхождение в особенностях эксплуатации между устаревшей и текущей версией увеличило вероятность реализации рисков. Поэтому важно понимать, какие именно это риски, и какие есть средства для их смягчения.
Риск №1: Снижение производительности
Главная ценность любого продукта заключается в его основной функциональности. В случае с СУБД речь идёт о надёжном хранении структурированных данных, достаточно быстром доступе к ним и оперативном внесении изменений. Функциональность, связанная с защитой данных, мониторингом нагруженности и шибок, также является важной, но не первостепенной. В первую очередь необходимо, чтобы СУБД хранила наши данные, позволяла их быстро извлечь и модифицировать. В случае если данных много, задача быстрого исполнения запросов встаёт с особенной остротой. Причем за оперативность реализации отвечает не только аппаратное и программное обеспечение, но и автор запроса. Известно, что язык извлечения и манипулирования данными – SQL – является языком запросным, т. описывающим в своих конструкциях, какой именно результат хочет получить отправитель задания. Конкретный алгоритм построения результата при этом в большинстве случаев никак не фиксируется. Однако, такой алгоритм всё равно нужен. Он называется «план исполнения запроса», и генерируется внутренним компонентом СУБД – оптимизатором запроса. Естественно, что при смене версии СУБД поменяется и версия оптимизатора, а значит – велика вероятность того, что на те же запросы будут построены другие планы. Более того, меняются компоненты СУБД, отвечающие за исполнение элементов плана, а также становятся доступны новые элементы для планов исполнения запросов. Впрочем, пугает не столько новизна движка базы данных с оптимизатором, сколько риск того, что на наших данных и нашем потоке запросов планы окажутся менее производительными. Выражаясь проще: есть риск того, что при обновлении версии СУБД важные запросы станут исполняться медленнее настолько, что это вызовет недовольство пользователей.
Риск №2: Потеря совместимости
Любая СУБД является не самостоятельным приложением, а лишь слоем хранения данных для бизнес-приложений. Предприятию важно, чтобы именно эти приложения работали исправно и быстро, а это обеспечивается в том числе и совместимостью между бизнес-приложением и связанной с ним СУБД. Самый первый уровень совместимости – возможность подключения к СУБД. В этой части опасаться особенно нечего, поскольку мы обсуждаем переход между версиями одной и той же СУБД – обеспечить в этом месте обратную совместимость достаточно просто, и производитель это делает. Гораздо серьёзней риск несовместимости диалекта SQL. В самом деле, реализация SQL в конкретной СУБД меняется от версии к версии – появляются новые возможности и устаревают имевшиеся ранее. Конечно, из соображений обратной совместимости устаревший синтаксис некоторое время принимается СУБД, но производитель оставляет за собой право в конце концов исключить его из языка. Если это произойдёт, то запросы с устаревшими элементами синтаксиса перестанут работать, и приложения, их отправляющие, потеряют, по меньшей мере, часть своей функциональности. И ещё одна точка несовместимости – изменение в структурах хранения данных. Может изменяться толкование стандартных типов данных или условия хранения ёмких типов. Конечно, как и в случае устаревшего синтаксиса, устаревшие структуры данных тоже поддерживаются некоторое время из соображений обратной совместимости, но рано или поздно они могут быть исключены из СУБД и тогда наступает несовместимость. Пути устранения синтаксической и структурной несовместимости очевидны – переписать часть кода бизнес-приложений так, чтобы появилась совместимость с новой версией СУБД. Даже в случае наличия поддержки бизнес-приложения, это может занять значительное время. Правда, производители бизнес-приложений для крупных предприятий, как правило, отслеживают выход новых версий, и у них имеются готовые варианты, совместимые с актуальными версиями смежного ПО. Тем не менее, обновление бизнес-приложения – это отдельный ёмкий процесс. Как временное решение могут помочь режимы совместимости в СУБД.
Риск №3: Снижение безопасности
Любой программный продукт имеет ошибки и уязвимости, которые обнаруживаются только в процессе эксплуатации. Кроме этого, новая функциональность и связанные с ней риски в области защиты данных на этапе запуска ПО ещё плохо известны техническому персоналу, поэтому возможны ошибки администрирования, также приводящие к ослаблению безопасности. В старом продукте есть известное количество уже обнаруженных уязвимостей, исправленных обновлениями от производителя. Поэтому кажется, что более ранняя версия более защищена. Однако, это чувство защищенности мнимое – действительно, много заплаток уже поставлено, но никто не знает, сколько дыр ещё осталось. А с учётом того, что старая версия продукта снимается с поддержки, риск злонамеренной эксплуатации открытой уязвимости резко возрастает. Поэтому специалисты как правило придерживаются мнения, что с новой версией ПО не связывается повышение риска – любая поддерживаемая версия, любого ПО имеет примерно одинаковую вероятность попасть под «атаку нулевого дня». И для любой версии методы смягчения этого риска одни и те же: сужение поверхности атаки, настройка безопасности внутри приложения, аудит нетипичной активности и своевременное применение обновлений безопасности.
Смягчение рисков 1 и 2
Методика смягчения рисков снижения производительности и потери совместимости заключается в предварительном тестировании. Необходимо настроить временный экземпляр СУБД и создать в нём полную или частичную копию производственной БД. На продуктивной базе записать типичную активность пользователей за длительный период. Если типичная активность меняется от периода к периоду (например, активность в часы пиковой нагрузки, в отчётный период, в выходные дни и нерабочее время), то можно или записать активность одной сессией, охватывающей все такие периоды, или сделать несколько коротких сессий записи активности в периодах разного типа. Потом записанная активность запускается на копии базы данных — с целью убедиться в отсутсвии сбоев и снижения производительности. Более изящный способ требует хорошего знания характера запросов, приходящих в БД. Впрочем, если администратор БД озабочен её производительностью, он обычно знает все «тяжёлые запросы» и может проконтролировать их производительность, не прибегая к записи текущей активности пользователей. Проверку совместимости можно переложить на производителя бизнес-приложения, просто убедившись, что в списке совместимых СУБД присутствует та версия, на которую необходимо перейти.
Только в том случае, если в тестовой среде было обнаружено, что реализуются риски снижения производительности или потери совместимости, необходимо проводить работы по ликвидации последствий. Эти работы совпадают с рутинными задачами поддержания производительности на должном уровне при эксплуатации систем – обнаружение тяжёлых запросов, построение полезных и удаление вредных индексов, установка полезных и снятие вредных «намёков» оптимизатору и т. Хорошая практика – удалять периодически старые средства оптимизации и создавать новые «с нуля». В плане обеспечения совместимости СУБД и бизнес-приложений необходимо вести работу с производителями последних, добиваясь версий, совместимых с актуальной версией системы управления базами даннных. В любом случае – подобные операции проводятся на тестовой копии БД и не влияют на работу пользователей. Только когда на тестовой среде достигается приемлемая работоспособность на новой версии СУБД, может быть принято решение о миграции на нее.
Прежде, чем приступать к миграции, необходимо убедиться, что доступна актуальная резервная копия переносимой БД, и имеется проверенная процедура восстановления из резервной копии. Если чего-то из перечисленного нет, это необходимо создать и иметь в оперативном доступе в процессе миграции.
Существуют два принципиально разных подходах к миграции – in-place и out-of-place. В первом случае обновление накатывается прямо на старую версию ПО, в надежде на то, что удастся корректно перенести все настройки. Однако, помимо риска некорректной работы мастера обновления на продуктивной среде, есть ещё и недоступность БД в процессе такой миграции, и невозможность быстро отскочить на исходную позицию (к старой версии). Поэтому наилучшей практикой является второй вариант – в инфраструктуре заказчика настраивается новая версия СУБД, в которую переносится продуктивная БД и применяются средства устранения проблем с производительностью и совместимостью. Затем в эту БД переводится работа пользователей. В случае неожиданных особенностей эксплуатации новой версии СУБД работа пользователей переводится обратно в старую версию СУБД, а исполнители миграции возвращаются к устранению обнаруженных проблем.
Стратегия в отношении обновлений
Итак, мы рассмотрели обстоятельства, которые могут привести к решению отложить обновление версии СУБД, и увидели, что это лишь усугубляет возможные проблемы, поскольку чем старше используемая версия, тем выше вероятность возникновения негативных последствий и серьезных нестыковок. Поэтому переход на новую версию СУБД следует планировать заранее — по мере выпуска новых версий, с учётом ранее озвученных рисков и механизмов их смягчения.
Однако, стоит вспомнить ещё одно средство, позволяющее нам оптимизировать управление обновлениями. Речь идёт о переносе баз данных в «облако». Если говорить о конкретной ситуации с окончательным устареванием MS SQL Server 2008, то такой перенос сегодня позволит ещё на некоторое время оттянуть наступление неизбежного. Дело в том, что эта версия SQL Server в Azure получит три года бесплатного продления обновлений безопасности (Extended Security Updates), и проблемы, с которыми столкнутся пользователи «наземных» MS SQL Server 2008 сегодня, для пользователей «облачных» продуктов наступят значительно позже. При этом и пользователи «наземных» SQL Server тоже смогут воспользоваться продлением обновлений безопасности, но при соблюдении определённых условий и за отдельные деньги.
Перенос сервисов в «облако» позволяет снизить нагрузку на технический персонал пользователя системы, в том числе и по применению обновлений. Это можно считать ещё одним доводом в пользу миграции баз данных в Azure.
Эксплуатация снятой с поддержки СУБД существенно увеличивает риски в области безопасности и стабильности работы бизнеса. При переходе на новую версию СУБД существует вероятность снижения производительности, потери совместимости и снижения безопасности. При этом риск снижения безопасности является мнимым. В свою очередь риски снижения производительности и потери совместимости смягчаются опытной эксплуатацией в изолированной среде. При выявлении проблем их устраняют, пользуясь стандартными процедурами, аналогичными тем, что используются при оптимизации работы действующей системы. Перед миграцией на новую версию СУБД должна быть обеспечена резервная копия и процедура восстановления. Наилучшим способом миграции является out-of-place – с сохранением старой версии сервиса для быстрого отскока назад при обнаружении неожиданных проблем.
Помимо технических нюансов миграции на новую версию SQL Server, так же существуют и лицензионные вопросы, которые при неправильном подходе несут в себе серьёзные риски частичного покрытия серверов лицензиями и, соответственно, нарушение лицензионной политики вендора.
При переходе на новую версию рекомендуется провести аудит установленных копий SQL Server и количество подключений к ним. Изучить текущие схемы лицензирования и выбрать для себя оптимальный вариант.
На данный момент существует две основные редакции SQL Server 2017 – Standard и Enterprise. Редакция Standard сохранила «классическую» схему лицензирования – «server + CAL», которая подразумевает, что каждая серверная лицензия дает право запускать программное обеспечение только в одной физической или виртуальной операционной среде одновременно, однако клиент может использовать любое количество запущенных экземпляров SQL Server в этой операционной среде. И не стоит забывать про клиентские лицензии, которые нужны для всех пользователей или устройств, которые подключаются к SQL Server в сети организации. Вторая модель лицензирования изменилась по сравнению с SQL 2008. И заключается в подсчёте всех ядер, которые физически присутствуют на данном сервере. При лицензировании «по ядрам» клиентские лицензии SQL CAL покупать для этого сервера не надо. При лицензировании виртуальных машин, считаем только ядра, которые были выделены для этой ВМ. Вне зависимости от среды развёртывания, необходимо лицензировать минимум 4 ядра.
Схема лицензирования редакции Enterprise изменилась, и теперь необходимо считать количество ядер, которые в физической среде присутствуют на сервере, либо – в ВМ выделены для этого экземпляра SQL Server. И так же, как и у редакции Standard, – минимальное количество ядер для лицензирования составляет 4 шт. А если полностью лицензировать сервер путем покупки лицензий SQL Server 2017 Enterprise с подпиской Software Assurance с учетом общего числа физических ядер в серверах, клиенты получают возможность развертывать неограниченное число виртуальных машин.
За дополнительными консультациями обращайтесь к специалистам MERLION
Сбор информации
Изучите возможности новой программы. Вы должны заранее знать, чего можно от нее ждать. Пользуйтесь документацией, материалами с сайта информационно — технологического сопровождения, тематическими форумами.
Опишите методики отражения хозяйственных операций в текущей программе. При этом используются типовые механизмы или они основаны на доработках? Можно реализовать эти методики в новой программе без внесения изменений? Если изменять, то что — методику или планировать доработки?
Проверьте, поддерживает ли новая программа ваше «железо», операционные системы, другое программное обеспечение. Составьте список на обновление.
Если составлен список обновлений (ОС, ПО, железо) — выберите поставщиков, согласуйте спецификации, запланируйте и утвердите бюджет.
Выберите инструмент перехода. Если используется решение стороннего разработчика (например, «Помощник перехода Камин — ЗУП, ЗГУ, КА, ERP») — изучите его документацию, проконсультируйтесь по возможности внесения необходимых Вам доработок, исправлений, сроках и расписании работы службы техподдержки.
Подготовка
Обучите пользователей (и обучитесь сами) работе в новой программе. Особенное внимание — методикам отражения ваших хозяйственных операций. Только еще приступая к работе с новой информационной базой, ваши пользователи уже должны уметь их учесть.
Подготовьте краткие инструкции по отражению хозяйственных операций в новой программе для тех методик учета, которые планируется использовать. Если прежние методики не поддерживаются — разработайте новые.
Для консультаций, настройки системы обязательно привлекайте ключевых сотрудников — руководителей направлений, бухгалтеров, работников кадровой службы и др. Они — ваши помощники. Именно от их заинтересованности в результатах проекта зависит, как программу будут воспринимать другие пользователи.
Время перехода
Лучше всего, если переход на новую программу совпадет с началом нового финансового и налогового периода. Особенно — для программ, предназначенных для расчета заработной платы. Особенно — в целях корректного составления формы 6-НДФЛ (для программ, предназначенных для расчета зарплаты и кадрового учета).
При выборе времени обязательно учитывайте, поддерживается ли производителем ваша текущая программа. Переход крайне желательно запланировать до завершения поддержки.
Проектная команда
Если учетная система, из которой планируется выгрузка данных, небольшая (сотрудников в информационной базе до 100 человек, количество видов расчета — не более 20, не используются сделки, не ведется учет договоров ГПХ, нет сложных начислений и т. ) справиться с переносом данных может и один человек. Например, многие программисты и консультанты «1С» имеют бухгалтерское образование, заканчивали бухгалтерские курсы, читают периодику, в курсе последних изменений законодательства в области кадрового учета и расчета зарплаты.
Если такой сотрудник работает в штате вашего предприятия — считайте, что Вам крупно повезло. Но если это не так, то понадобится создание проектной команды.
Обязательно согласуйте с руководителем проектную команду и перечень работ, разработайте план — график их участия в проекте.
Помните, только лишь один программист, системный администратор (непосредственно выполняющий переход) не может и не должен отвечать за успешность проекта в целом. Перенос данных (особенно больших данных) — всегда командная работа.
Составьте план «Б». Всегда должна оставаться возможность вернуться на старую программу или работать в новой, но в другом режиме, если что-то пойдет не по запланированному сценарию.
Тестовые переносы
Подготовьте прежнюю программу — обновите, удалите помеченные объекты, выявите и исправьте ошибки, пересчитайте итоги.
Проведите тестовые переносы данных. Ваша цель — добиться сопоставимости перенесенных данных. Обязательно учитывайте разницу в архитектуре программ. Далеко не все данные можно сопоставить «лоб в лоб». Составьте список отчетов для проверки.
Дайте пользователям возможность поработать в тестовой базе. Они освоятся в новой программе, сверят перенесенные данные, введут новые документы и проверят их работу, получат нужные отчеты. Результат переноса устроил — согласуйте настройки, зафиксируйте договоренности на бумаге.
Составьте сценарий своих действий при переносе данных, чтобы ничего не забыть и сэкономить время.
После того, как в результате тестовых переносов данных удалось добиться сопоставимости результатов, переходите к финальному переносу.
ВНИМАНИЕ!!! Учет в тестовой базе вести нельзя — она предназначена только для отработки механизмов переноса и выработки методик настройки.
Финальный перенос
Заранее известите пользователей о дате и времени проведения работ по переносу данных, если возможно — запретите на это время вход в прежнюю программу.
Выделите необходимые ресурсы. Внезапно окончившееся место на жестком диске или отключение электричества значительно уменьшают шансы уложиться в заранее согласованные сроки.
Перенесите данные и выполните заключительные действия — создайте и настройте пользователей, назначьте группы и шаблоны доступа, подключите программу к интернет-поддержке, загрузите базовые классификаторы, настройте программу по заранее согласованным договоренностям.
Запретите ввод данных текущего периода в прежнюю программу.
Первое время после перехода будьте готовы к неожиданностям. Каким бы продуманным и хорошо организованным ни был проект перехода на новую программу, почти всегда находятся мелочи, которые забыли учесть, вовремя не обратили внимание и т.
Продолжайте развивать план «Б» — планируйте параллельную работу 2-х систем или возможность вернуться на прежнюю.
Переход на любую современную программу — это сложный, многоэтапный процесс. К нему обязательно нужно готовиться. Следуйте этим простым советам, и Ваш проект перехода обязательно будет успешным.