среда, 8 октября 2008 г.

Конверт для компакт-диска

Вот когда приспичит в очередной раз, воспользуюсь, а то конвертиков для всякой ерунды не напасешься!



И еще много других способов.

понедельник, 15 сентября 2008 г.

Банкротство Lehman Brothers и кредитные рейтинги.

Любой, кто хотя бы немного интересуется экономикой и финансами, знает (или слышал), хотя бы об одном из мировых рейтинговых агенств. Названия Moody's, Fitch, Standard & Poor's всегда на слуху и раньше у меня вызывали большое уважение. Теперь уважения стало меньше. Ну, вот объясните мне, для чего существуют рейтинги всех этих агенств, и как вообще на них можно хоть в чем то опираться, если до самого последнего момента все вышеперечисленные агенства устанавливали весьма высокие рейтинги банка Lehman Brothers, вплоть до момента, когда этот американский банк объявил о намерении подать прошение о банкротстве в американский суд по банкротствам. Чтобы не быть голословным: до 15 сентября агенство Fitch выставляло банку Lehman Brothers долгосрочный рейтинг А+, который означает "Высокая кредитоспособность. Рейтинги уровня "A" обозначают низкие ожидания по кредитным рискам. Способность своевременно погашать финансовые обязательства оценивается как высокая." А потом сразу рейтинг D, т.е. дефолт, да и то только после объявления банка о банкротстве. И вот спрашивается зачем нужен такой рейтинг, что он показывает? Да, получается - ничего! Ведь о том, что у Lehman Brothers дела идут плохо, и что они активно искали кому бы продаться, уже не одну неделю писали во всех финансовых новостях. Вопрос, на который лично у меня нет ответа, почему ведущие мировые рейтинговые агентсва, несмотря на известные факты плачевного состояния дел в одном из крупнейших банках США, не изменяли соответствующим образом его кредитные рейтинги?

вторник, 9 сентября 2008 г.

Data Mining не может заменить аналитика

Замечательная цитата:

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

(Отсюда)

пятница, 1 августа 2008 г.

Время прихода на работу и дисциплина.

На глаза попалась хорошая статья про два различных подхода к тому должны ли все сотрудники приходить на работу в одно и тоже время, например, строго к 9, или же возможен гибкий график, когда каждый приходит в то время когда, ему удобнее, но соблюдая при этом определенные правила.
Совсем недавно я пытался объяснить руководству, почему я не настаиваю, чтобы сотрудники моего отдела приходили ровно в 9, но вот сам написать такую статью и привести хорошие аргументы, как в этой статье (http://bishop3000.livejournal.com/35767.html) не смог. Думаю, что, если бы я вооружился аргументами из этой статьи, моя позиция была бы убедительнее.

понедельник, 30 июня 2008 г.

Хорошее описание ошибки.

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

Возьмем, для примера, заявку увидев которую и возникло желание написать этот пост:
Заявка от пользователя, зарегистрированная сотрудником 1 линии поддержки:
Просьба рассмотреть вопрос и принять необходимые меры по внесению своевременных изменений данных в базе товара Axapta. Менеджеры говорят о том, что резервируемое кол-во тех или иных позиций в течение нескольких часов / дня не списывается, что приводит к неверному информированию секретарями клиентов. Таким образом, преподносимая информация на 2-ю половину дня не является актуальной.

А вот ответ более опытного коллеги, сразу чувствуется, что второй матерый:
Не понятно:
Какие своевременные изменения должны происходить в Аксапте?
По словам каких менеджеров?
Что значит резервируемое количество тех или иных позиций?
Что значит резервируемое количество не списывается?
Куда преподносится информация и почему считается, что она не актуальна?
Где смотрится данная информация (полный путь)?
Абсолютно не понятна проблема пользователя.
Следует уточнить, что и где смотрит пользователь, какие данные хочет получить и какие ошибки возникают?
Если пользователь считает что какие то данные не актуальны, то нужны конкретные примеры.

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

Просто покажите новичку такую памятку:

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

  1. При работе в каком приложении происходит ошибка? Программа должна быть одной из списка, программ на сопровождении. При этом требуется узнать конкретное название программы.
  2. Какое действие делает пользователь перед возникновением ошибки? Желательно указать пункт меню.
  3. Как должно быть? Какой результат ожидал получить пользователь? Например:
    • ввести данные
    • напечатать отчет
    • что еще?
  4. Желательно узнать, когда пользователь перестал получать ожидаемый результат. Другими словами, когда работало? Например, «Вчера в 18:30 программа работала, а сегодня в 10:00, уже нет»
  5. Если ошибка происходит при входе пользователя в программу, то необходимо выяснить выполнил ли пользователь вход в сеть.
  6. Нужно узнать, есть ли еще пользователи, выполняющие такие же (или аналогичные) действия, у которых при этом нет проблем.
  7. Если пользователь сообщает о проблеме с каким-то отчетом, то нужно узнать параметры, заданные при формировании отчета.
Каждое хорошее описание ошибки должно содержать ровно три вещи:
  1. Какие шаги привели к ошибке.
  2. Что вы ожидали увидеть.
  3. Что вы в самом деле увидели.

пятница, 27 июня 2008 г.

Hyper-V ну очень ожидаемый релиз.

Вот такую вот картинку наблюдал сегодня утром открыв Google Reader комментарии излишни:



среда, 14 мая 2008 г.

Правило умной ошибки.

Хочу рассказать про одно простое правило, которое может здорово облегчить сотрудникам службы поддержки пользователей их работу. Сложность современных бизнес-приложений вообще, и например ERP-систем в частности, такова, что держать все настройки, и все возможные ситуации в голове одному человеку сложно, да и не нужно. Если вы, что то забыли, то всегда можно обратиться к документации, которая поставляется вместе с системой, а также к той документации, которую вы создали сами. Но, вот ведь в чем беда - зачастую для того чтобы решить пустяковую задачку сотрудникам поддержки приходиться "перелопатить" кучу документации, а также потратить немало времени создавая примеры на тестовых приложениях.
Облегчить повседневную работу можно, если использовать правило, назову его правилом умной ошибки, которое состоит в том, что любое сообщение об ошибке или информационное сообщение, которое ваша система выдает на экран, должно содержать идентификатор этой ошибки, по которому можно быстро и легко найти дополнительную подробную информацию о причинах её возникновения.
Приведу простой пример:
Допустим от пользователя поступила заявка, что мол "Я не могу выписать счет, т.к. система ругается "Не указан ответственный менеджер по клиенту ХХХ". Если сотрудник поддержки уже встречался с такой ошибкой, то конечно, он быстро разберется, где в настройках клиента указывается ответственный менеджер, а вот если он встретился с такой ошибкой в первый раз, то вынужден будет вначале самостоятельно разобраться, кто такой ответственный менеджер, за что он ответственный и почему, если он не указан нельзя выписать счет клиенту, где его нужно указать, и кто это должен сделать.
И вот тут на помощь приходит умное сообщение об ошибке, которое могло бы выглядеть, например так: "Не указан ответственный менеджер по клиенту ХХХ (см. NKS-11348)", где NKS-11348 - это ссылка на подробное описание этой ошибки. Описание может быть в виде статьи в базе знаний, или просто ссылкой на какой-то раздел руководства пользователя. Особенно актуальной такая идентификация каждой ошибки становиться, если вы вносите модификации в стандартный функционал вашей ERP-системы. В этом случае даже опытному консультанту без подобной "подсказки" будет трудно разобраться в нестандартном "поведении системы".
Несмотря на всю очевидность и простоту этого правила, к сожалению, разработчики приложений зачастую им пренебрегают. А ведь, если всегда придерживаться этого правила в разработке, то последующая работа с вашим приложением, выполнение настроек и разрешение трудных ситуаций становятся гораздо менее трудоемкими занятиями.

понедельник, 14 апреля 2008 г.

Зарплатные SMS.

У нас в компании зарплата перечисляется сотрудникам на карточки. С того времени, как все сотрудники получили карточки уже прошло достаточно большое время. И сегодня я получил подтверждение, что большинство сотрудников уже освоились с карточками и современными банковскими услугами. Когда сегодня в большем кабинете, одновременно неожиданно начали звонить почти все мобильники, вначале я был довольно сильно удивлен - с чего бы это вот так, вдруг, штук примерно 10 мобильников зазвонили! Объяснение нашлось тут же. Оказалось, что многие мои коллеги подписались на услугу оповещения об изменении баланса на карточном счете, и когда на карточки была перечислена зарплата, пришли SMS оповешающие об этом. Этот веселый перезвон мобильников был встречен конечно же всеобщим одобрением :)

пятница, 22 февраля 2008 г.

Лояльные пользователи - залог успеха проекта внедрения ERP

Много раз я читал и слышал, что одним из ключевых факторов успеха при внедрении ERP систем является привлечение пользователей на "свою" сторону. А сейчас я на своем опыте очередной раз убеждаюсь в верности этого утверждения. У нас в компании мы сейчас завершаем этап модификаций нашей ERP Axapta. И вот на днях я услышал слова нашего главного бухгалтера: "это даже лучше чем в 1С". Это было произнесено когда консультант показывала ей что-то в Axapta.
Надо сказать, что до совсем недавнего времени, пользователи в нашей компании относились к Axapta, мягко говоря не очень дружелюбно. И поэтому когда я услышал "комплимент" в адрес Axapta от бухгалтера, которая до недавних пор была убеждена, что лучшая на свете бухгалтерская программа - это 1С, я был приятно удивлен.
Я думаю, что немалую роль в перемене взгляда на нашего главного бухгалтера на систему Axapta сыграло общение с одной из консультантов по системе, которая с одной стороны отлично знает возможности Axapta, а с другой стороны знает потребности российского бухгалтера привыкшего работать в самой лучшей программе для манипуляции бухгалтерской отчетностью, в 1С :), и используя эти знания, агитировала и убеждала, что работать в новой системе можно более эффективно, если использовать возможности, которые предоставляет система, хотя некоторые из этих возможностей на первый взгляд скрыты или неочевидны.
Обучение пользователей, особенно ключевых, приемам эффективной работы в системе в процессе внедрения и завоевание их симпатий - это ключевой фактор успеха. Пользователи, у которых работа в новой системе начинает получаться лучше и проще чем раньше, становятся активными помошниками в процессе внедрения.

понедельник, 21 января 2008 г.

Новый профессиональный журнал по системам автоматизации управления предприятием.

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

Темы журнала:
Сфера корпоративных систем автоматизации по направлениям:
- решения по классификации ERP CRM BI EAM MES и другие;
- единые и крупные решения, малофункциональные решения;
- отраслевые решения;
Архитектурные решения автоматизации SOA, SaaS, решения интеграции;
Системы управления базами данных;
Сервера и сетевое оборудование;
Безопасность в корпоративных системах и оборудовании;
Карьера, работа в ИТ (статьи, вакансии, резюме, хобби и увлечения ИТ-специалистов).

Для корпоративных читателей подписка бесплатна. Для того чтобы подписаться нужно зарегистрироваться на сайте http://erpnews.ru/, затем зайти в профиль и указать "Да" в пункте "Подписка на печатный журнал ERPNEWS".

P.S.
Я подписался, так что надеюсь почитать первый номер.