ipmi

Осмотр настроек BIOS, удаленное включение выполняется посредством IPMI. Названия технологии IPMI у разных вендоров разные:
— для Cisco — это Cisco IMC (Integrated Management Controller)
— для DELL- это iDRAC (Integrated Dell Remote Access Card)
— для HP — это iLO (Integrated Lights-Out)
— для IBM и Lenovo — это IMM (Integrated Management Module)
— для Supermicro — это SIM (Supermicro Intelligent Management)

вспомогательные файлы 1С

  • def.usr — хранится в каталоге <Данные приложений пользователя>/1C/1Cv8/<Идентификатор информационной базы> (например, C:/Documents and Settings/User/Application Data/1C/1cv82/4129dbdb-b495-41cb-99ea-ef315060a03e/def.usr) и содержит имя пользователя который последним открывал данную информационную базу.
  • ibases.v8i — хранится в каталоге <Данные приложений пользователя>/1C/1CEStart (например, C:\Documents and Settings\user\Application Data\1C\1CEStart\ibases.v8i) и содержит список информационных баз, зарегистрированных на данном клиентском компьютере. Этот список отображается в диалоге «Запуск 1С:Предприятия».
  • GenTempl_ru.st, GenTempl_en.st  — стандартный файл шаблонов текста расположен в каталоге загрузочных модулей 1С:Предприятия (например C:/Program Files/1cv82/bin) на русском и английском языке соответсвенно.
  • appsrvrs.lst — хранится в каталоге <Данные приложений пользователя>/1C/1cv82 (например, C:/Documents and Settings/User/Local Settings/Application Data/1C/1cv82/appsrvrs.lst) и содержит список серверов 1С:Предприятия, зарегистрированных в утилите администрирования информационных баз в варианте клиент-сервер.
  • srvribrg.lst —  хранится на центральном сервере кластера в каталоге <рабочий каталог центрального сервера> (например, C:/Program Files/1cv82/server/srvribrg.lst) и содержит список кластеров, зарегистрированных на данном компьютере сервера 1С:Предприятия. Содержащиеся в нем данные необходимы для нормальной работы приложений, использующих данный сервер 1С:Предприятия.
  • 1CV8Reg.lst — файл настройки кластера( например C:\Program Files\1cv82\srvinfo\reg_1541\1CV8Reg.lst)
  • В каталогах DBNameCacheConfigSaveConfigSICache хранится множество файлов, кеширующих различные компоненты конфигурации. Эта информация является производной от конфигурации информационной базы, хранимой в базе данных, и служит для ускорения запуска клиентских приложений и повышения их производительности. Кеш конфигурации располагается в каталоге данных приложений текущего пользователя, например, C:/Documents and Settings/User/Local Settings/Application Data/1C/1cv82/7b0a6294-d6a3-41c5-a23e-dc9e5301ad22/DBNameCache.
  • В каталоге 1Cv8FTxt хранятся данные, используемые службой полнотекстового поиска. Они располагаются на компьютере центрального сервера 1С:Предприятия в каталоге <рабочий каталог кластера>/<идентификатор информационной базы>. Например: C:/Program Files/1cv82/server/reg_1541/7eac7609-c0cb-4701-83cf-9ff5f8961de8/1Cv8FTxt.
  • Группа файлов CACHE/ddb<n>.snp хранится в каталоге хранилища конфигурации и служит для кэширования запрошенных версий конфигурации из этого хранилища. Наличие этих файлов не является обязательным и позволяет ускорить получение версий конфигурации.
  • *.1ccr — конфигурационный файл Web-сервиса для работы с удаленным хранилищем может иметь произвольное имя (расширение 1ccr обязательно), формат XML и содержит единственный узел с произвольным именем и атрибутом connectString — в этом атрибуте указывается адрес сервера хранилища в схеме tcp.
  • *.mft — файл с расширение mft является файлом-манифестом — специальным файлом, описывающим шаблон конфигурации. Файл может иметь произвольное имя. Файл располагается в каталоге установленного шаблона конфигурации.
  • *.v8i — в данном файле приводится описание формата файла описаний зарегистрированных информационных баз. Данный список используют все клиенты. Файл располагается на локальном компьютере в каталоге %APPDATA%\1C\1CEStart\ и по умолчанию имеет имя ibases.v8i.
  • 1CESCmn.cfg — файл 1CESCmn.cfg содержит общие настройки программ запуска (1CEStart.exe и 1Cv8s.exe).
  • 1CEStart.cfg — файл 1CEStart.cfg содержит настройки, которые используют программы запуска (1CEStart.exe и 1Cv8s.exe) и клиентские приложения (1Cv8.exe и 1Cv8c.exe). Файл расположен в каталоге %APPDATA%\1C\1CEStart.
  • adminstall.cfg — файл adminstall.cfg указывает на то, что установка системы программ «1С:Предприятие» выполнялась с использованием средств администрирования операционной системы. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие» и представляет собой текстовый документ в кодировке UTF-8.
  • comcntrcfg.xml — файл comcntrcfg.xml служит для указания внешнему соединению необходимости запуска в отладочном режиме.
  • Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие», и его наличие не является обязательным.
  • conf.cfg — файл conf.cfg определяет расположение каталога общих конфигурационных файлов. Файл расположен в каталоге bin\conf каталога конкретной версии «1С:Предприятия» и представляет собой текстовый документ в кодировке UTF-8.
  • debugcfg.xml — файл debugcfg.xml предназначен для настройки дополнительного диапазона портов, используемого при отладке конфигураций. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие», и его наличие не является обязательным.
  • def.usr — файл хранится в каталоге %APPDATA%\1C\1Cv82\<Уникальный идентификатор информационной базы> и содержит имя пользователя который последним открывал данную информационную базу.
  • default.vrd — данный файл служит для настройки веб-клиента и использования Web-сервисов, и находится в каталоге виртуального приложения.
  • inetcfg.xml — файл inetcfg.xml позволяет задавать настройки прокси по умолчанию и имеет больший приоритет над настройками прокси по умолчанию в Windows. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие», и его наличие не является обязательным.
  • logcfg.xml — файл logcfg.xml служит для настройки технологического журнала. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие», и его наличие не является обязательным.
  • logui.txt — располагается в каталоге %APPDATA%\1C\1Cv82\<Уникальный идентификатор информационной базы> и содержит список интерактивных действий пользователя, которые выполнялись за время журналирования.
  • nethasp.ini — для настройки параметров взаимодействия системы «1С:Предприятие» с HASP License Manager используется конфигурационный файл nethasp.ini. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие», и его наличие не является обязательным.
  • nhsrv.ini — некоторые настройки HASP License Manager могут задаваться при помощи файла конфигурации nhsrv.ini. При запуске HASP License Manager осуществляет поиск конфигурационного файла nhsrv.ini в различных каталогах в следующей последовательности:
    • каталог, в котором размещается исполняемый файл HASP License Manager;
    • текущий каталог Windows;
    • системный каталог Microsoft Windows (%SystemRoot%\system32 — для 32-разрядной версии и %SystemRoot%\system — для 64-разрядной версии);
    • каталог Microsoft Windows;
    • каталоги, перечисленные в переменной окружения PATH (только в случае установки HASP License Manager как приложения Microsoft Windows).

Рекомендуется размещать файл nhsrv.ini, если это необходимо, в каталоге, в котором размещается исполняемый файл HASP License Manager. Проверка того, что HASP License Manager нашел и прочитал файл конфигурации, можно с помощью журнала Activity Log/Server Activity Log.

  • srv1cv82 — конфигурационный файл /etc/sysconfig/srv1cv82 используется для задания параметров запуска агента сервера «1С:Предприятие» с помощью скрипта /etc/init.d/srv1cv82. Данный конфигурационный файл используется в случае запуска сервера «1С:Предприятия» в операционной системе Linux.
  • swpuser.ini — для того чтобы рабочий процесс запускался не от имени того же пользователя, что и агент сервера, в каталоге данных приложений, относящемся к пользователю агента сервера, может быть размещен файл swpuser.ini
  • *.lic — лицензии базовых конфигураций (C:\Documents and Settings\All Users\Application Data\1C\licenses)

А давайте выкинем плохую программу и купим хорошую?

Достаточно популярна практика решения проблем маханием шашкой.

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

Особенности 8.3.14

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

Реализован упрощенный OLAP . Теперь можно работать на чтение с копией таблицы с ведомой СУБД.
Реализовано событие технологического журнала <DBCOPIES>.Механизм копий базы данных требует лицензию КОРП.

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

Добавлен альтернативный механизм управления сервером 1С программно и кроссплатформенно, реализован объект АдминистрированиеСервера . Дополнительно смотрите https://wonderland.v8.1c.ru/blog/razvitie-klastera-serverov/

Улучшен механизм счетчиков  потребления ресурсов — реализована возможность отбора по признаку использования безопасного режима работы и профиля безопасности (добавлены новые типы фильтров).Для выражений отбора счетчика потребления ресурсов реализована возможность сравнения на неравенство. Для выражений отбора счетчика потребления ресурсов реализована возможность объединять «по И» несколько условий на один тип фильтра.

Реализован пакетный режим работы тонкого и толстого клиентских приложений. Пакетный режим распространяется от начала запуска клиентского приложения до окончания работы обработчика ПередНачаломРаботыСистемы модуля приложения. После окончания работы обработчика пакетный режим автоматически отключается. В пакетном режиме запуска подавляется вывод любых диалогов системы. Признаком пакетного режима работы клиентского приложения является команда командной строки запуска /DisableStartupDialogs.

Больше не поддерживается интерфейс 8.2

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

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

Ускорено выполнение реструктуризации информационной базы при использовании СУБД Microsoft SQL Server и IBM DB2.

Уменьшилась вероятность одновременного закрытия множества соединений с Microsoft SQL Server, что положительно влияет на производительность работы с TempDB.

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

Для динамического списка реализована возможность указания полей, которые будут использоваться в качестве ключевых полей выборки. Повышена производительность при использовании динамических списков с отсутствующей основной таблицей. Например, для динамического списка без основной таблицы, стало возможно использование группировки. Дополнительно смотрите https://wonderland.v8.1c.ru/blog/razvitie-dinamicheskikh-spiskov-s-proizvolnymi-zaprosami/

 Больше не поддерживается IE. У поля, имеющего вид ПолеHTMLДокумента, изменится с COMОбъект на ВнешнийОбъект. Ухудшится Windows-совместимость. Дополнительно смотрите https://wonderland.v8.1c.ru/blog/perevod-klientskikh-prilozheniy-dlya-windows-na-ispolzovanie-webkit-optimizatsiya-otobrazheniya-html/

В тонком, толстом и веб-клиентах, форма снимает блокировку объекта через 1 минуту после снятия признака модифицированности.(раньше снималась при закрытии формы)При работе под управлением СУБД PostgreSQL, в технологический журнал (событие <plansql>) помещаются планы запросов для запросов UPDATEDELETE и INSERT. (Раньше был только SELECT)

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

В технологическом журнале реализованы свойства DbmsDatabaseDBCopy для событий обращения к СУБД (DB2DBMSSQLDBPOSTGRSDBORACLE), событий EXCP и SDBL.

 Добавлен Механизм решения систем линейных алгебраических уравнений

смотрите https://wonderland.v8.1c.ru/blog/mekhanizm-resheniya-sistem-lineynykh-algebraicheskikh-uravneniy/

Подробнее http://downloads.v8.1c.ru/content//Platform/8_3_14_1565/1cv8upd_8_3_14_1565.htm

Статистика которую можно получить из базы данных PostgreSQL

Таблица Описание
pg_stat_activity Каждая строка показывает: процесс сервера, OID базы данных, имя базы данных, ID процесса, OID пользователя, имя пользователя, имя приложения, адрес клиента и порт,время, текущею транзакцию, текущий запрос, статус процесса, текст запроса. Колонки показывающие данные текущего запроса доступны если параметр track_activities включен. Эти колонки доступны только для суперпользователя или пользователя владельца процесса.
pg_stat_bgwriter One row only, showing cluster-wide statistics from the background writer: number of scheduled checkpoints, requested checkpoints, buffers written by checkpoints and cleaning scans, and the number of times the background writer stopped a cleaning scan because it had written too many buffers. Also includes statistics about the shared buffer pool, including buffers written by backends (that is, not by the background writer) and total buffers allocated.
pg_stat_database Одна строка: OID базы данных, имя базы данных, количество процессов подключенных к базе, кол-во транзакций примененных и отмененных, количество прочитанных блоков, количество попаданий в буфер, количество выбранных, переданных, добавленных, обновленных и удаленных строк.
pg_stat_all_tables Для каждой таблицы в текущей базе данных (включая TOAST таблицы): OID таблицы, схема и имя таблицы, количество последовательны просмотров, количество строк выбранных запросами, количество просмотров индексов (все индексы данной таблицы), количество строк выбранных через сканирование индексов, количество: пересечений строк, обновленных, удаленных строк, количество обновленных HOT строк, количество живых и мертвых строк, время последнего ручного vacuum, время последнего автоматического vacuum, время последнего ручного analyze, время последнего автоматического analyze.
pg_stat_sys_tables То же что и pg_stat_all_tables, только системные таблицы
pg_stat_user_tables То же что и pg_stat_all_tables, только пользовательские таблицы
pg_stat_all_indexes Для каждого индекса текущей базы: OID таблицы и OID, схема, имя таблица и индекса, количество просмотров индекса, количество записей возвращенных при сканировании индекса, количество живых строк таблицы полученных простым сканированием индексов используя этот индекс.
pg_stat_sys_indexes То же что и pg_stat_all_indexes, только системные таблицы
pg_stat_user_indexes То же что и pg_stat_all_indexes, только пользовательские таблицы
pg_statio_all_tables Для каждой таблицы текущей базы данных (включая TOAST таблицы), OID таблицы, схема и имя таблицы, количество блоков прочитанных с диска, количество попаданий в буфер, количество блоков прочитанных с диска и попавших в буфер для всех индексов таблицы, количество блоков прочитанных с диска и попавших в буфер that table’s auxiliary TOAST table (if any), количество блоков прочитанных с диска и попавших в буфер для индекса TOAST таблиц.
pg_statio_sys_tables То же что и pg_statio_all_tables, только системные таблицы
pg_statio_user_tables То же что и pg_statio_all_tables, только пользовательские таблицы
pg_statio_all_indexes Для каждого индекса текущей базы данных: OID таблицы и индекса, имя таблицы и индекса, количество блоков прочитанных с диска и попаданий в буфер.
pg_statio_sys_indexes То же что и pg_statio_all_indexes, только системные таблицы
pg_statio_user_indexes То же что и pg_statio_all_indexes, только пользовательские таблицы
pg_statio_all_sequences Для каждой последовательности в текущей базе данных: OID последовательности, схема и имя последовательности, количество прочитанных блоков с диска и попаданий в буфер.
pg_statio_sys_sequences То же что и pg_statio_all_sequences, только системные таблицы
pg_statio_user_sequences То же что и pg_statio_all_sequences, только пользовательские таблицы
pg_stat_user_functions For all tracked functions, function OID, schema, name, number of calls, total time, and self time. Self time is the amount of time spent in the function itself, total time includes the time spent in functions it called. Time values are in milliseconds.
pg_locks Информация о блокировках в базе

Человеческий фактор во внедрении процессов и инструментов или где лучше приживаются инструменты?

Автор Новичков Александр Николаевич
Где лучше приживаются инструменты? Странный вопрос – конечно там, где есть схожие инструменты и технологии! Может сказать читатель и будет прав лишь отчасти. Если у заказчика есть похожие технологии и инструменты, то зачастую это только мешает, так как психологически, каждый из нас отвергает все новое.
Существует несколько факторов, оказывающих негатив на процесс внедрения, отметим лишь самые важные:

  1. Длительность работы с инструментом – наиболее очевидный фактор – чем дольше –  тем больше привыкли, тем сложнее перейти на новое.
  2. Возраст специалиста – это наиболее интересный фактор, который сам по себе абсолютно ни о чем не говорит. То есть при внедрении можно делать небольшую корректировку на возраст, но только вместе с первым фактором можно говорить о существенном влиянии на конечный результат.
  3. Удовлетворенность текущим инструментарием – фактор “а мне и так все подходит” можно назвать блокирующим – он существенно влияет на результат.

Это были объективные критерии, рассмотрение которых было бы неполным без таких мощных субъективных как:

  1. Нежелание переходить на новую технологию, так как она осуществляет более глубокий контроль над деятельностью исполнителя
  2. Элементарное саботирование…

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

А ПРИМЕР?

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

  • Не те сборки отдаются не тем заказчикам;
  • Документирование ошибок ведется вручную;
  • Журнал ошибок в word;
  • метрики не собираются;
  • Планирования нет (вернее есть планы, которых никто не придерживается);
  • Задачи на разработчика вешаются устно;
  • И так далее…

Все усугубляется тем, что сегмент рынка показывает бурный рост – сама компания сверхуспешна, что позволяет бизнесу смотреть сквозь пальцы на чрезмерные издержки отдела ИТ.
Наверное просто необходимо отметить разобщенность отделов ИТ и полную несплоченность команды. А всем известно, что сплоченность команды имеет очень важное значение успешности проекта.
Хаос в чистом виде!
Часть команды решает, что так жить нельзя и решает навести порядок.
Первое и последнее, что сделано – создана самописная система управления изменениями. Сама система являет собой классику кустарной системы – только учет и только запросов одного типа. Управлять из нее реально можно только задачами, причем не маленькими задачками с одним ответственным, а глобальными задачинами, разбитыми по этапам, за каждым этапом закреплен один ответственный и куча соисполнителей, то есть масса владельцев на одну задачу.
Любой перенос сроков любого этапа приводил к ручному переделыванию всеми ответственными сроков собственных этапов.
Отдельно об этапах. Этапы  выстраиваются в некий водопад, где предусматривается возврат не только на предыдущий, но и на любой вышестоящий – как сочтет правильным руководитель этапа. Ясно, что он не всегда прозорливо угадывает, куда именно вернуть (особенно, когда не определены четкие критерии возврата). Ненужно говорить, что после подобной “итерации” ничего не подозревавший владелец другого этапа крайне удивлен тому, что согласованная задачи через три головы вернулась назад.
Такой подход можно считать правильным только в том случае, когда компания работает на динамично меняющемся рынке – только тогда работы могут быть пересмотрены и возвращены в самое начало – на анализ. В любом другом случае понятно, что в организации нет анализа и управления требованиями.
Вернемся к системе управления изменениями – при все порочности система прижилась, так как лучше хоть какой учет вместо никакого… Система жила и росла полтора года.
Настал час внедрения IBM Rational. Заказчик мягко намекнул, что процессы ему выстраивать не надо. Нужно только автоматизировать существующие. Апелляция к логике, осведомленным источникам  и высшим силам не возымела действия! Клиент уверен, что У НЕГО ЕСТЬ ПРОЦЕССЫ, которые надо автоматизировать. Нас продавили только двумя железными аргументами “клиент всегда прав” и “кто платит деньги?”. Пришлось взять расписку об ответственности за неуспех и приступить.
Автоматизация УК и УИ (управление конфигурациями и управление изменениями) пошла в жизнь. Внедрение ClearCase прошло без сбоев. Проблем не возникло – так как ничего похожего у заказчика не было, то решение прижилось. Чистое версионное хранилище может вызвать отторжение только неправильной настройкой. В данном случае все было «ок».
ClearQuest же не внедрился… Это, возможно, первый прецедент в  нашей практике когда не внедрилась система УИ даже в беспорядочном процессе.
Устроим разбор полетов: итак, заказчик привязан к существующей системе и не готов не только менять процессы, но не готов видеть иные экранные формы в системе автоматизации. Получилось так, чтобы выполнить проект необходимо на ClearQuest повторить функционал системы заказчика. То есть выполнить весь некорректный процесс но в другой системе – одна мегасущность и куча соисполнителей.
Естественно, что функциональные возможности ClearQuest позволяет сделать все. Мы повторили функционал, как нас и просили. Только в итоге системой пользоваться никто не стал. Получалось, что все огрехи стали еще более очевидны. Заказчик, в свою очередь, принял решение о том, что данная технология ему не нужна.

СКРЫТЫЕ (ПОДВОДНЫЕ) КАМНИ:

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

Итог:

Система развернута и  сдана. Заказчиком мило похоронена…
Потрачена куча времени и ресурсов практически впустую.

Грустно? – да!
Неудачное внедрение? – еще как неудачное!
Консультантов на мыло?! – возможно, да, но рамки проекта не позволяли нам действовать.

Чем сердце успокоилось…

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

Анализ разбора полетов

Далее мы попытаемся проанализировать проблемы и дадим рекомендации по их устранению, но с учетом того, что у вас есть возможности по продвижению решений:
Незаинтересованное руководство – отсутствие политической воли практически всегда – провал проекта. Руководство нужно убеждать и доказывать. Если не получается – проблему надо эскалировать. Если это не помогает – пытаться пойти снизу и убедить специалистов. Потом  общей массой доказать правоту руководству.
Почему ничего не вышло у нас?
Выше нашего руководителя только совет директоров компании – нет возможности эскалировать. Ниже специалисты, которым и так хорошо, а вторая часть разработала схожее решение. Фактор “от добра добра не ищут” сыграл на 100%
Возраст специалистов – в чистом виде у него есть влияние, но не пагубное. То есть человеку можно объяснить и несколько раз показать. Но в совокупности с отсутствием политической воли получаем крах.
У нас был ряд проектов, в которых процессы ставились и автоматизировались персоналом, чей средний возраст далеко за 56 лет… И ничего – порядок
Наличие аналогичной  системы – в чистом виде тоже не помеха. Очевидная эффективность ClearQuestперед самоделкой позволит продемонстрировать руководству получение ощутимых результатов. Здесь руководство должно было проявить прозорливость и объяснить своим, что их система помогла в трудное время, но надо идти вперед. Самое главное – продемонстрировать, что разработчики старой не будут сокращены.
В данном случае все этого и боялись…
Внедрение от инструмента – путь в могилу. Нельзя автоматизировать хаос. Любое внедрение должно начинаться с осмысления процессов (с последующим переосмыслением).
В  нашем случае заказчик настаивал только на внедрении инструментов.
Зрелость организации – даже если девять беременных женщин собрать вместе – ребенок родится через девять месяцев. Зрелость и сплоченность коллектива идут рядом. Если организация не сплоченная и незрелая то трудно будет  внедрить инструмент. Здесь нужна воля руководства + процессы + время на их реализацию. Время дозревания.
В нашем случае заказчик дозрел в течении 4-5 месяцев, после того как мы “плешь проели” на всех уровнях, что так нельзя…