Запрещение или контроль «скрытых ИТ…». Кто должен писать и поддерживать специальные программные приложения?

61

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

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

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

Имеет ли смысл пытаться контролировать или запрещать разработку приложений, выполняемую за пределами ИТ-отдела (за исключением незначительных вещей, таких как макросы Excel)?

matcauthon
источник
3
Будет зависеть от окружающей среды. Вы можете настроить ОС на рабочем месте так, чтобы только администраторы могли устанавливать новое программное обеспечение, вы можете запретить доступ к соответствующим ресурсам на сервере (базы данных, файловая система), к которым у этого программного обеспечения должен быть доступ. Вы можете сделать это технически, так что это невозможно, можно избежать выдачи паролей, IP-адресов и другой необходимой информации или просто сделать это политикой компании и уволить всех, кто не соблюдает требования. Я видел более или менее все это.
Торстен Мюллер
40
Но если эти «скрытые программы» действительно важны и не могут быть реализованы настоящим ИТ-отделом, что вы получите, запретив их? Они важны в конце концов, поэтому вы просто не можете позволить себе их не иметь. Может быть, реструктурировать свой ИТ-отдел? Или переориентировать? Мне кажется понятным, что умелые люди делают вещи вне обычного рабочего процесса, если этот рабочий процесс не отвечает ...
Андрес Ф.
13
@ thorstenmüller На этом этапе вы в конечном итоге получаете скрытые программы, реализуемые в виде формул Excel, что обеспечивает на порядок меньшую удобство обслуживания, чем даже Excel VBA. Поскольку создание электронных таблиц Excel - это способность, которая нужна многим офисным работникам, вы не можете полностью запретить ее, как любую более подходящую платформу разработки.
Дэн Нили,
5
@ thorstenmüller Моя точка зрения такова, что независимо от того, что вы пытаетесь делать, когда выбор идет по каналам, выждите несколько дней (если не месяцев из-за неурядиц), потратите несколько часов на то, чтобы сделать это вручную, или проведите обходной обход политики сделать последнее. Предполагать, что вы можете остановить это бред. Лучшее, на что вы можете надеяться, - это эффективный процесс поиска и применения этих инструментов после факта.
Дэн Нили,
16
Что плохого в том, что «обычные люди» автоматизируют свои бизнес-процессы? Пока это на самом деле экономит их время, что, вероятно, так и есть, я считаю это хорошей вещью . Если конкретный «грязный» «специальный» инструмент автоматизации сильно зависит от него, возможно, стоило бы, чтобы разработчики написали поддерживаемую версию. В худшем случае, когда требования меняются, им приходится снова начинать работу вручную, но, по крайней мере, они уже сэкономили много времени!
Филипп

Ответы:

79

Раньше я работал в компании, где каждое приложение, которое мы им давали, вызывало вопрос: можем ли мы экспортировать эти данные в Excel?

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

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

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

Можно утверждать, что это означало, что мы неправильно расставили приоритеты, что важная работа не была выполнена. Но я бы сказал, что это позволило более высокооплачиваемым разработчикам выполнять более сложную работу. Что это может повредить?

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

прецизионный самописец
источник
36
Я работал в аналогичной среде, и реакция нашего отдела на эти «приложения» всегда была разочаровывающей. Многие мои колледжи в отделе ИТ почему-то чувствовали угрозу от этих приложений, но я считал их замечательными. Это позволило пользователям отделов выяснить, что им действительно нужно, и когда эта единственная база данных Access не работала на них, они могли просто передать ее нам, и мы создали бы «реальное» решение SQL для поддержки той же функциональности. Я бы убил за такой проект снова. Все требования были известны в первый день, когда мы начинали.
Грэм
8
+1 Хорошо сказано. Расширение возможностей пользователей нашего программного обеспечения должно быть одним из наших главных приоритетов.
Стивен Эверс
Я бы согласился по большей части с вашим ответом. Но суть в том, что плохо написанные запросы могут повредить сервер базы данных; даже если написано в Excel или Access. Когда-то приходится балансировать обязательства SLA по ИТ с потребностями бизнеса.
Стив
@ Стефан: Да. И именно поэтому лучше дать пользователям возможность заниматься своими делами, чем позволять им получать производственные данные. Будь то ежедневная копия данных, предназначенная только для чтения, экспорт в Excel или DSL, во многом зависит от ваших требований безопасности / SLA и их требований к данным.
PDR
1
@mattnz: я бы настоятельно рекомендовал против этого. Это дает людям возможность заставить техническую команду расставить приоритеты по своим проблемам над остальной частью бизнеса, просто собрав что-то вместе и сказав: «Вы понимаете, почему это не работает?» Вы когда-нибудь знали разработчика, который мог бы противостоять таким вызовам?
PDR
50

Я думаю, что люди упускают общий смысл здесь:

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

Почему эти приложения создаются в первую очередь?

Во всех случаях, которые я видел, есть общая причина:

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

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

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

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

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

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

SqlRyan
источник
2
+1 место на. Я не вижу здесь никого, кто бы упоминал о том, что может быть огромной проблемой с этими практиками, которые я видел во многих компаниях. То, что работает для одного или двух человек в краткосрочной перспективе, быстро превращается в огромный капризный программный беспорядок из 30 небольших приложений, которые выросли за годы, примерно половина работы и их обслуживание в десять раз дороже, чем если бы отдел ИТ нанял людей сделать все из них, чтобы они были последовательны и имели центральную базу владения ИТ.
Джимми Хоффа
4
Как человек, который работает программистом «black ops», я могу вам сказать, что часто у ИТ нет навыков, необходимых для понимания потребностей конкретного технического отдела. Некоторые из наших наиболее важных и инновационных программ начинались как программы «Black Ops». ИТ - это не то место, где инновации поощряются, инновации и эксперименты часто означают множество неудачных проектов для каждого успешного. После того, как программа «Black Ops» хорошо принята, ее, как правило, передают в ИТ-отдел для обслуживания.
Билл
+1 Мои мысли точно, но сформулированы гораздо лучше.
Фил
16

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

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

Вы проводите несколько вечеров, чтобы написать приложение, которое выполнит всю работу. Вы показываете это на своем персональном ноутбуке своим коллегам, и они находят это очень полезным. Вы хотите установить его на ПК компании, но у вас должно быть согласие ИТ-отдела. Вы просите об этом, но они отклоняют это, потому что они не поддержат ваше приложение.

Разве это не звучит глупо?

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

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

Арсений Мурзенко
источник
2
«По моему опыту, такие случаи чрезвычайно часты». - То есть ваша компания проделывает потрясающую работу, нанимая хороших программистов на непрограммистские работы, а затем плохих программистов на программирование? Я думаю, что более вероятно, что кто-то, кто не понимает практики и лежащие в основе системы, подумает, что он пишет лучшее программное обеспечение. Просто мои 2 цента.
Ominus
2
@Ominus: если есть вакансия для адвоката, компания будет искать адвоката; если кандидат также является опытным разработчиком, интервьюер может даже не знать об этом. Так что нет, компания не «нанимает хороших программистов на непрограммистскую работу»: они нанимают квалифицированного специалиста для работы, не зная, что этот человек - отличный разработчик.
Арсений Мурзенко
@ Ominus: обратите внимание, что когда вы, например, работаете клерком, вы не говорите во время интервью, что вы отличный программист. Для многих людей, не имеющих технического образования, программист = хакер = чувак, который будет тратить свое время на взлом компьютеров компании = много проблем.
Арсений Мурзенко
1
@ Ominus - Компания не должна быть плохой в найме ИТ-специалистов, чтобы иметь некомпетентный ИТ-отдел. Плохие отделы ИТ могут возникать, потому что ИТ кто-то считает «накладными» и сокращает его, насколько это возможно. Это вытягивает их за пределы их реальных возможностей, и они становятся некомпетентными как организация - постоянно переключаясь между задачами, режимом постоянной паники, ни с кем не общаясь, не выполняя обещаний.
Майкл Кон
2
@ Ominus: Что более вероятно здесь, так это то, что компания выполняет одинаково хорошую работу по найму обоих типов ролей, но тогда ИТ-группа обременена бюрократией, противоречивыми приоритетами и системой управления персоналом, которая не справляется с работой, удушая инновации, а не заботиться о ней. Специалистам, работающим не в сфере ИТ, после того, как их навыки замечены, разрешается сосредоточиться на задаче, поскольку только их руководитель контролирует их время. Люди, выполняющие реальную работу, автоматически принимают участие в инновациях, в то время как ИТ-группа не имеет той же точки зрения на потребности.
SqlRyan
6

Вы не можете полностью контролировать это ...

Я бы сказал, что вы никогда не сможете ПОЛНОСТЬЮ контролировать его, поскольку у сотрудников всегда будут средства для создания мошеннического кода и распространения его альтернативными способами. Так что не стоит слишком много зацикливаться на этом, если вы разработали и внедрили несколько основных правил и процессов и настроили несколько инструментов.

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

Но вы можете создать дружественную к коду среду

Многие компании, зачастую очень крупные, делают это. Хорошим примером является Google, представители которого заявили, что используют единый SCM для всей компании, чтобы каждый мог отслеживать и просматривать чужой код.

Я бы порекомендовал вам сделать следующее:

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

Тогда проблема заключается в распространении технологий. Очевидно, что некоторые предпочитают использовать X над Y, и тогда становится сложнее, чтобы они вписывались в вашу архитектуру. Тем не менее, это не невозможно, и если они хотят, чтобы их код был сохранен, они, вероятно, получат дополнительную милю, если, ну, это всего лишь одна миля.

Вы также можете занять более произвольную позицию и решить, что разрешены только языки L и Stack S, но тогда вы получите кое-какие мошеннические вещи, поэтому я бы порекомендовал немного их расширить. Некоторые CI-системы могут творить чудеса с несколькими плагинами, если ваши сотрудники готовы написать немного кода для склеивания или некоторые скрипты конфигурации, чтобы заставить их соответствовать.

Дайте командам свободу

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

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

Поговори с ИТ, вовлеки их

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

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

haylem
источник
3

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

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

Tangurena
источник
3

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

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

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

Кроме того, возникает проблема, заключающаяся в том, что, когда вы посмотрите на эти усилия, умноженные на сотни (или тысячи) отделов на предприятии из списка Fortune 500, вы вскоре обнаружите, что ваше предприятие имеет более 100 клиентских «основных» баз данных. Ваши клиенты начинают жаловаться на то, что они обновили свои контактные данные в одном месте, но в 10 других они все еще устарели, или что вы даже не знаете, как много вы работаете со своими крупными партнерами, потому что информация распространяется по 10 теням. ИТ базы данных.

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

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

Пэт Джеймс
источник
2

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

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

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

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

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

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

Стив
источник
1

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

  • Защищенные паролем Excel макросы, где единственный человек, который знает пароль покинул компанию,
  • Нести ответственность за неверные отчеты, написанные неопытными людьми, потому что это ИТ
  • Нас попросили изменить отчет, который мы никогда не видели и не слышали раньше.

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

Пол Т Дэвис
источник
5
Из того, что я понимаю, ИТ есть для поддержки бизнеса; Разве цель создания ИТ-отдела - помочь людям выполнять свою работу? Как они могут хорошо выполнять свою работу, если вы запрещаете им создавать необходимые им инструменты? Нет ничего плохого в том, чтобы сказать: «Не считайте нас ответственными за этот неверный отчет - кто-то в продаже создал это».
Фил
@Phil - Согласен. ИТ-отдел призван помочь бизнесу работать, а не выполнять какие-либо функции самостоятельно - его бы не было, если бы он не позволял бизнесу лучше выполнять свою работу, а все, что выполняет ИТ, следует рассматривать через призму того, как бизнес работает лучше благодаря их усилиям. Каждый процесс, созданный вне ИТ, соответствует потребностям, которые ИТ не удовлетворяет, и их запрет влечет за собой еще большую ненадежность. От вас нельзя ожидать поддержки процессов, которые вы не разрабатывали, и я был бы тверд, но отказ признавать, что эти «мошеннические» решения соответствуют реальным потребностям, просто упрям.
SqlRyan
1
Я должен добавить, что были приняты меры по расширению ИТ-отдела для удовлетворения этих потребностей.
Пол Т Дэвис
Хотя ИТ поддерживает бизнес, часто бизнес не поддерживает ИТ. Компании часто не учитывают время, которое потребовалось бы ИТ-специалистам для того, чтобы взять на себя руководство или консультирование по поводу сложных, разработанных конечным пользователем электронных таблиц или приложений. Чистый эффект - недоукомплектованный ИТ-отдел. И мы все знаем, как это работает.
Майк Шеррилл 'Cat Recall'
1

Если есть проблема здесь, это с отделом ИТ.

Нет ничего плохого в том, чтобы позволить людям со специальными знаниями в области бизнеса / области манипулировать и обрабатывать свои собственные данные.

ИТ-отдел должен признать это и поддержать его. Предоставляя повторно используемые интерфейсы, предоставляя данные в удобных форматах, таких как EXCEL или Access DB, и предоставляя гибкие инструменты (COGNOS, Jasper Reports и т. Д.).

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

Джеймс Андерсон
источник
1

Разочарование многих компаний или отделов в компаниях состоит в том, что их ИТ-отделы мешают им выполнять свою работу или делать что-то новое. Это приводит к тому, что департаменты, которые чувствуют, что их сдерживают ИТ-политики, пытаются решить свои собственные проблемы. Общение является ключевым. Если отделы работают над ИТ, то у вас действительно есть проблемы с ИТ. ЭТО не может позволить себе быть врагом. Компании, и особенно ИТ-отделы, должны понимать, что им нужно работать вместе, а не друг против друга. Если отделы общаются со своими ИТ-специалистами (особенно теми, кто должен осуществлять надзор) и рассказывают им о своих потребностях и о том, как они работают над решением своих собственных проблем, По крайней мере, у ИТ-специалистов будет возможность помочь решить проблемы, а не узнавать после того, как наступит кризис. Держите это в курсе.

Натан Пиллинг
источник
1

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

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

  • Весь код должен регулярно передаваться в систему контроля версий, управляемую ИТ. ИТ должны свободно создавать учетные записи и каталоги, чтобы сделать это возможным. Это может даже хотеть дать некоторую инструкцию.
  • Все, что включает в себя PII (личную информацию), аутентификацию, авторизацию, криптографию, данные, защищенные законом, или данные, которые бизнес считает важными, должно включать и быть одобрено консультантом из ИТ. ИТ / консультант должен предоставить помощь, библиотеки и т. Д., Чтобы должным образом защитить бизнес и обеспечить разработку приложений.
  • Первичные базы данных должны быть защищены. В зависимости от базы данных доступ для чтения должен быть относительно легким, а доступ для записи - более сложным. ИТ может потребоваться предоставить учетные записи, ведение журнала или аудит.

Включение имеет много преимуществ.

  • ИТ узнает больше о том, как удовлетворить потребности своих клиентов. Это приводит к лучшей расстановке приоритетов и обмену.
  • Это рассматривается как друг и выгода, а не проблема.
  • Реальные деловые потребности удовлетворены.
  • Бизнес-данные должным образом защищены, потому что были задействованы ИТ, что исключает необходимость в задних дверях.
  • Инструменты Deparment не теряются из-за оборота и могут быть легко перенесены в IT, если это необходимо.
walrii
источник
0

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

Вещи, которые вы можете сделать:

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

  • Сделайте так, чтобы все стажеры, связанные с ИТ, работали только через ИТ

  • Ограничение через ОС политикой установки программного обеспечения . Каждая установка программного обеспечения должна проходить через службу поддержки ИТ, требуя одобрения руководителя. Таким образом, установка чего-то вроде MS Access, PHP, Visual Basic и т. Д. Будет труднее пройти незамеченной.

  • Выпустите политику, утверждающую, что каждая новая разработка, чтобы получить поддержку, должна быть написана, скажем, на Java, C #, C ++ или любом другом языке, который потребовал бы крутой кривой обучения . Таким образом, вы сводите мир людей с «определенными знаниями в программировании» к беспорядкам.

  • Специалисты по требованиям должны взглянуть на «решения Excel» вокруг компании, потому что это отражает ИТ-потребности корпорации.

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

Но: ни одна вещь, которую вы делаете, не превзойдет по силе телефонный звонок от Большого Шефа , который позвонит ИТ-менеджеру и попросит его поддержать приложение, созданное стажером.

Тулаинс Кордова
источник
Что касается пункта 1, то автономные приложения могут оказать большую помощь в обработке данных даже без БД, а в пункте 4 крутая кривая обучения никогда не мешает кому-то писать материал, когда он лежит в его основе, результат которого будет еще хуже поддержка или даже что-то вроде «мне не нужно это приложение поддерживается»
трещотка урод
Пункт 3 об ограничении ОС не работает. Многие компании уже перешли на модель «принеси свой ноутбук».
Sulthan
5
Я согласен с пунктом 4 (учтите, что пользовательские инструменты могут отражать отсутствие реакции со стороны ИТ), но не с остальными. Ограничительные меры пахнут бюрократией. По моему опыту, конечный результат - это то, что не делается , и редко в том, чтобы ИТ-специалисты были вовлечены эффективным образом. Например, «нет, вы не можете сделать X. Спросите менеджера и получите одобрение». (результат: X никогда не закончится; уровень разочарования возрастает)
Andres F.
0

Один из способов, которым моя компания помогает в подобных ситуациях, - не быть независимым от языка. Если вы хотите, чтобы приложение / программа даже рассматривалось, оно должно быть на выбранном нами языке (java). Мы можем немного расширить правила для некоторых JQuery или js, но это должно быть хорошо составленное приложение, которое удовлетворяет критически важную потребность. Не приходите и не говорите: «У меня есть это PHP-приложение, которое мне нужно, чтобы вы разместили для меня», потому что вам, вероятно, просто передадут лист политики.

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

Sedaition
источник
0

Высокомерие вундеркиндов!

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

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

Джеймс Андерсон
источник