Conselho do especialista em TI para o cliente ou como automatizar a bagunça

Olá pessoal, trabalho no negócio de TI (na parte que lida com a criação de sistemas de TI) há mais de 20 anos. Queria resumir a experiência em algumas dicas para o cliente de como tornar a automação da organização um projeto eficaz e bem-sucedido.

Sobre as metas e limites do projeto

Vamos começar definindo as metas que você deseja alcançar implementando um projeto de TI. Por fim, a TI nada mais é do que tecnologia com seus recursos. Mas a criação de um sistema de informação não pode ser um fim em si mesma. O objetivo deve ser estabelecido em termos de seus negócios.

Dica: Se você estiver pensando em um projeto de TI em larga escala, cobrindo muitas áreas da sua empresa, verifique se o objetivo foi acordado com a primeira pessoa e até com o Conselho de Administração, se houver. É melhor atrair a atenção da gerência para o projeto o mais cedo possível.

Após definir a meta, é necessário decidir quais processos de atividade serão afetados como parte da implementação do sistema de informação. A automação é sempre um processo de alteração dos processos de atividade. Certamente todos ouviram o slogan "você não pode automatizar uma bagunça". E é mesmo. A implementação de um sistema de informação exigirá que você defina com mais clareza os processos de atividade, métodos de tomada de decisão, do que é possível sem automação. É verdade que, como resultado, você obterá regras mais claras de trabalho e resultados comerciais previsíveis.

A definição de processos de atividade automatizada é a designação dos limites organizacionais (em termos de pessoas, departamentos) e funcionais (conjunto de funções que determinam o processo) de um projeto futuro.

Dica: No processo, pense nos limites do projeto. Muitas vezes, ao projetar um sistema de informação, quero "automatizar esse tipo de trabalho, e até esse". Tente não permitir isso. Cada novo recurso é uma quantidade extra de trabalho para você e os contratados.

Sobre o grupo de trabalho

Depois de determinar quais processos o projeto de TI afetará, você precisará de um grupo de trabalho! Deve incluir os funcionários da organização responsáveis ​​pela implementação dos mesmos processos que a automação afetará.
O grupo de trabalho deve determinar os objetivos de negócios do projeto e os requisitos funcionais para o sistema de informações que você deseja receber.

Dica: Foi por isso que falei anteriormente sobre a necessidade de alinhar as metas do projeto com a primeira pessoa da empresa. Na fase de formação do grupo de trabalho, os colegas podem resistir a mudanças futuras. Isso é normal! Mas é preciso estar preparado para isso. Por exemplo, ao concordar com as metas de um projeto de TI, você pode discutir a questão de motivar os participantes com o gerenciamento.

Formação de requisitos para um sistema automatizado

Como agilizar a discussão sobre tarefas de automação e requisitos funcionais? Existem duas abordagens:
1. Se os processos que você decidir automatizar forem bastante típicos, você poderá envolver profissionais na discussão - uma empresa de TI com experiência em automatizar processos semelhantes. Eles lhe dirão quais tarefas estão sendo resolvidas, quais processos são afetados e expressarão os requisitos funcionais. E você apenas edita essa lista para si mesmo.
2. Selecione no grupo de trabalho o principal especialista do setor cujas atividades serão mais afetadas. E escreva a primeira versão das tarefas e requisitos funcionais junto com ele.

O principal é obter o primeiro rascunho de tarefas e funções e depois esclarecê-lo, e não esperar que o grupo de trabalho o forme. A verdade básica é sempre mais fácil criticar do que inventar.

O próximo passo é a formação de requisitos técnicos

Aqui você precisa do diretor de TI da empresa. Sua tarefa é fornecer informações sobre como executar adequadamente um projeto de TI (em quais servidores, com quais canais de comunicação, sob o controle de qual sistema operacional, em quais linguagens de programação, usando quais produtos de software). Ou forneça requisitos para todos os itens acima, com base no entendimento dele do cenário de TI da sua empresa.

Quando passamos por essas etapas - consideramos ter uma tarefa técnica para um projeto de TI!

Seleção de empreiteiros

Em seguida, vem a virada do estágio organizacional: a escolha da empresa contratada. No mundo moderno, esse processo é organizado como um procedimento competitivo.

• Se você é uma empresa estatal e o sistema de informações é criado a partir do orçamento do estado, você possui 44 leis federais. De fato, regula todas as regras da competição.
• Se você é uma empresa com participação estatal, age com base nas 223 leis federais e em seus próprios regulamentos de compras.
• Por fim, se você é uma empresa privada, possui uma declaração de compra.

Não pode haver conselho universal. Mas eu recomendo que mesmo sua disposição de compras não exija isso, indique o preço máximo inicial do contrato e limite a porcentagem permitida de desvio em relação a ele . Porque Sim, porque todos os requisitos que você escreveu - cada licitante em potencial lerá à sua maneira. Ou aparecerá uma empresa que decide o que é importante para ela não fazer, mas apenas para conseguir um contrato.

Bicicleta: uma empresa (não sei o nome) decidiu criar um recurso de informação para todo o país. Esta não é uma estrutura estatal, e a liderança não limitou a bifurcação de preços acessíveis, desejando obter o maior número possível de opções.
75 empresas compareceram à competição. O cliente recebeu propostas para a implementação do seu TK com uma faixa de preço de 3 milhões a 300 milhões de rublos. E não pôde tomar uma decisão. A competição foi cancelada, as tarefas não foram resolvidas.

Dica: ao planejar o cronograma do projeto, lembre-se de que os procedimentos competitivos geralmente levam cerca de um mês.

Digressão nos tipos de projetos de TI

Antes de falar sobre os recursos da implementação do nosso projeto de TI, precisamos fazer uma pequena pausa e estipular que os projetos de TI são realmente diferentes. Quais?

Projetos de TI de infraestrutura
Um projeto de TI pode se concentrar na criação ou atualização de sua infraestrutura de TI. O que é chamado coloquialmente "mas vamos comprar servidores e impressoras".

Projetos de implementação de produtos de software
Um projeto de TI pode ser sobre a introdução de algum produto de software. Além disso, "horizontal" e especializado. Por "produto horizontal" no mundo da TI, entendemos um produto que, sem configurações adicionais, resolve a tarefa muito específica de automatizar uma função específica, necessária para todos os usuários. Um ótimo exemplo desse produto é o Microsoft Word. Todos nós entendemos que o Word é um sistema de informação? Mas eles se acostumaram ao fato de que ele é instalado de maneira simples e é fácil aprender isso. Isto é precisamente porque o sistema resolve um problema estreito: digitando com formatação, salvamento e impressão. E a tarefa é universal.
Produto de software especializado. Um exemplo é um sistema de contabilidade. Esse produto parece ter todas as funções necessárias para a contabilidade ... Mas! Cada empresa possui seu próprio plano de contas, análise de contas, participantes nos processos de aprovação e aprovação de documentos contábeis ... Ou seja, você precisa configurar o produto de software para o seu negócio.

Projetos para desenvolver uma solução única e sua implementação
Ainda existem projetos de TI para a criação e implementação de sistemas de informações exclusivos criados especialmente para sua empresa. Além disso, falaremos especificamente sobre as especificidades do gerenciamento de projetos desse tipo.

Dica: quero chamar a atenção para o fato de que, mesmo que você precise comprar impressoras em sua organização, recomendo fortemente que você formule os termos de referência aproximadamente da mesma maneira que eu disse anteriormente. Esta é uma fonte de economia. Como, começando a entender por que não há impressoras suficientes, pode ser que você tenha muitas impressoras de rede, que por algum motivo são usadas como “pessoalmente alguém”, e você não precisa comprar equipamentos, apenas altere as configurações. Vai sair muito mais barato. Eu acho que todo mundo vai concordar comigo.

Uma observação sobre a complexidade do projeto ou grandes sistemas de informação.
No mundo dos sistemas de informações corporativos, “grande” é chamado de sistema que automatiza mais de 10 processos de negócios. E se você estiver criando exatamente esse sistema, é especialmente importante entender como gerenciar um projeto para sua criação e implementação.

Implementação do projeto. Trabalho do cliente

A seguir, falaremos sobre um projeto para criar e implementar um sistema de informação com funções únicas e específicas.

A competição é realizada e você tem um executor de projeto de TI. A fase de implementação começa.Nesta fase, o grupo de trabalho (aquele que formulou as tarefas funcionais) é ainda mais importante. Somente agora ele incluirá representantes do artista.

Se o contratado é um profissional, ele sabe que é necessário iniciar o projeto com uma assembléia geral de todos os envolvidos e a aprovação da Carta do projeto . E é mesmo. É a Carta do projeto que permite prescrever as regras para a interação das equipes do contratado e do cliente. Em TK e no contrato, em contraste com a Carta, geralmente não existem detalhes como sobrenomes responsáveis ​​por decisões de design muito específicas.

Portanto, é importante que os guardiões do conhecimento sobre essas funções específicas da sua organização sejam participantes ativos do projeto. O risco de envolvimento insuficiente de especialistas do setor por parte do cliente é que, como resultado, o sistema de TI não levará em conta as especificidades necessárias e, na melhor das hipóteses, você não poderá implementá-lo (os funcionários não poderão usá-lo) e, na pior das hipóteses, a empresa perderá simplesmente sua vantagem competitiva no mercado. que ela tinha, mas de repente não foi automatizada ...

A empresa parceira para o desenvolvimento do sistema nem sempre é versada nos seus negócios. Especialistas em analistas e desenvolvedores por parte do contratado podem ouvir atentamente seus desejos e oferecer soluções mais ideais em termos de especificidades de automação, mas não sabem como conduzir seus negócios.

Sobre como gerenciar o desenvolvimento de um sistema de informações

Aqueles que se depararam com sistemas de TI provavelmente já ouviram os termos "cascata" (ou "cascata") de desenvolvimento e ágil . Vou falar um pouco mais sobre a diferença. Tradicionalmente no mundo da TI, a padronização das abordagens de desenvolvimento levou a uma metodologia em cascata para a criação de soluções de TI. De fato, você deve admitir que qualquer padronização tem um objetivo: quem faz alguma coisa, o resultado será exatamente como planejado. Uma abordagem em cascata fornece isso. Sua essência está em três palavras: primeiro, projetaremos, descreveremos nos documentos e, em seguida, escreveremos o código do programa, verificaremos como ele funciona com os documentos da tarefa técnica e do projeto técnico - e pronto! O que eles queriam, eles conseguiram. Parece conveniente trabalhar para todos os participantes do projeto, tanto o contratado como o cliente. Há apenas um problema: o tempo. Embora todos tenhamos planejado, o mundo mudou, surgiram novos tipos de atividades nos seus negócios, a equipe mudou, as áreas de responsabilidade foram redistribuídas. E o sistema em sua forma antiga agora não é realmente necessário.
O que é Agile (ou Scram)? Essa é uma metodologia para criar um sistema de TI em "pequenos pedaços", quando dividimos a tarefa em subtarefas que podem ser desenvolvidas e testadas em duas semanas - um mês. Essa é a ideia. Qual é o problema? É dividir a tarefa em "partes independentes". Infelizmente, isso quase nunca acontece.

E acontece que nem o desenvolvimento em cascata nem o Agile são uma panacéia. Portanto, o que quer que se diga, o gerenciamento de projetos de TI exigirá o uso de ambas as abordagens.

Organização do trabalho no lado do cliente, algumas dicas

1. Antes de iniciar a “automação de tudo”, você precisa identificar tarefas de alta prioridade (um conjunto de processos em que a falta de automação dificulta a vida).

2. Discuta dentro da empresa como esses processos automatizados trocarão informações com os processos de negócios relacionados.

Eu vou explicar Você decidiu automatizar o fluxo de trabalho, com seus colegas percebendo que as cartas recebidas da organização de gerenciamento são perdidas. Você decide - automatizar não todo o fluxo de trabalho, mas apenas o registro de entrada. Nesse caso, você deve decidir se a entrada será registrada eletronicamente e a saída - não, será adequada para você? E como isso vai funcionar? Se você respondeu a estas perguntas, sinta-se à vontade para fazer um projeto para automatizar o processo de registro de cartas recebidas. Esta etapa é chamada "Determinando os limites funcionais do projeto" . Depois disso, você também pode identificar especificamente os participantes, ou seja, os limites organizacionais do projeto e tornar o projeto visível. Para ele, será possível aplicar pelo menos um método em cascata, pelo menos ágil.

3. Se uma área de automação tão pequena não puder ser alocada, tente esta abordagem: encontre um contratado na fase de redação das especificações técnicas e solicite não apenas especificações técnicas, mas também o desenvolvimento de layouts simples para as partes mais importantes do sistema.

Lembre-se: é importante garantir o interesse da liderança no projeto. Mostre a ele os layouts dos painéis: quando eles aprenderem a obter todos os dados para esses painéis claros, será mais conveniente tomar decisões. Isso ajudará a economizar anos de trabalho e milhões de rublos.

A propósito, é ótimo criar protótipos de acordo com a metodologia Agile. Você pode resolver rapidamente, criar, mostrar tudo e, se necessário, ajustar as expectativas. De fato, o Agile surgiu como uma técnica de prototipagem rápida, e não para a criação de sistemas de TI industriais e estáveis.

4. Para que a empresa use um determinado sistema de TI que cubra todos os processos de atividade, a equipe precisa de um Comitê de Arquitetura permanente. Este é um grupo de seus funcionários (isso é obrigatório) que monitorará a criação, uso, mudanças, inovações no mercado, ou seja, será responsável pela integridade e ideologia comum. Geralmente, o comitê é gerenciado pelo CIO, mas especialistas do setor também devem ser incluídos.

5. No TK, além dos requisitos funcionais e técnicos, os requisitos de documentação são sempre apresentados - exatamente quais descrições do sistema de TI devem ser fornecidas pelo contratado. Torne essa parte dos requisitos ideal para uso futuro.

Lembre-se de que o contratado pode mudar e, se o sistema não estiver documentado, o novo contratado começará do zero!

O processo de criação de um sistema por uma organização externa não significa que seus funcionários "não façam nada e aguardem a implementação". Você e o contratado estão discutindo documentos, decisões particulares de design, resultados intermediários. Isso é importante para entender. Se isso não for feito, o contratado automatizará suas idéias sobre o seu negócio, e não o próprio negócio.

Talvez você já queira fazer a pergunta: “Senhor, quanto tempo o projeto levará tempo e dinheiro?”. Sobre isso no final do material.

Agora, quero falar mais sobre os dois últimos estágios do ciclo de vida de um projeto de TI: implementação e operação.

Organização do processo de implementação

Assim, o grupo de trabalho de gerenciamento de projetos, em conjunto com o contratado, adotou o sistema. Para onde ela levou e o que fazer a seguir?

Tradicionalmente, a primeira aceitação significa o início da operação de teste . Muitas vezes, pouca atenção é dada a essa etapa. E ele é importante. Idealmente, durante a operação de teste, você seleciona 1-2 pessoas e as treina no sistema: coloque-as no local de trabalho (ou dê acesso) e elas começam a realizar parte do trabalho usando o novo sistema.

Observe que os métodos antigos de desempenho de suas funções ainda estão em vigor. Ou seja, os participantes da operação de teste trabalham duas vezes! Não se esqueça de motivá-los!

O objetivo da fase de operação piloto é garantir que seja possível trabalhar no sistema. Não fornece resultados e erros inesperados, é conveniente o suficiente para ela usar. Se houver erros, inconvenientes, algo mais “incorreto”, eles serão registrados no “Journal of trial operation”. O contratado deve eliminar os comentários.

O que fazer se não se tratasse de comentários insignificantes, mas se esquecesse de todo o processo? Infelizmente, minha resposta não vai agradar. Se isso for esquecido logo no estágio do ToR - o contratado não corrigirá o erro às suas próprias custas. Pois ele dirá que "eles não pediram isso" e ele estará certo. Você terá que discutir com o contratado a conclusão de um contrato adicional ao contrato, termos e dinheiro adicionais.

Após a operação de teste, haverá funcionários capazes de trabalhar no sistema de TI. Eles poderão ajudar os colegas a aprender uma nova maneira de trabalhar diariamente. A operação piloto geralmente dura de 1 a 3 meses.

Após corrigir as deficiências identificadas pelo contratado, o sistema é aceito para operação comercial e se torna uma solução de combate para os negócios. O ato de aceitação em operação comercial completa formalmente o projeto de TI.

Duas palavras sobre treinamento de pessoal

Lembramos que alguns dos funcionários (participantes da operação de teste) já passaram no treinamento organizado pelo contratado. O que fazer com outros funcionários? Eles precisam ser ensinados. Você pode envolver especialistas treinados e um contratado neste trabalho. Ambas as opções são aceitáveis. Lembre-se de que o processo de aprendizado é sempre "pago". Você paga explicitamente esses serviços ao contratado ou precisa distrair sua equipe do trabalho principal para treinar colegas.

Como esse processo pode e deve ser otimizado? Peça ao artista para preparar aulas de vídeo, organizar o treinamento em sua organização, por exemplo, em casa, passar no teste. Se você incluir uma posição sobre a necessidade de desenvolver um curso em vídeo com tarefas de teste no contrato com o contratado, terá a oportunidade de treinar novos funcionários durante todo o período de operação.

Outro ponto organizacional que é importante lembrar ao colocar o sistema em operação comercial. Um ato é um ato, mas é importante refletir sobre o processo de transição para trabalhar no novo sistema. Um exemplo:

1. Você determina a data a partir da qual TODAS as operações são executadas no novo sistema. Infelizmente, as pessoas não são perfeitas. Portanto, aconselho não apenas a marcar uma data, mas também a fornecer uma ferramenta motivadora.
2. Como regra, essa data não é "amanhã após a assinatura do ato", mas após algum período, geralmente chamado de período de transição. Durante esse período, a organização vive em dois mundos: o antigo e o novo. De fato, o período de transição é como uma operação de teste estendida, apenas com todos os usuários.

Dica e conto: Como as pessoas tendem a resistir ao novo, lembre-se de que os funcionários ficarão descontentes com o novo sistema. Dirão que nada é claro e tudo é lento, que com suas próprias mãos teriam feito tudo há uma hora. Não se assuste, e lembre-se de que o objetivo da automação - infelizmente - nem sempre é torná-la "mais rápida", mas sempre garantir transparência e contabilidade completas para todas as operações.

Vou lhe contar um exemplo antigo, mas eficaz, de motivação para implementação. Um sistema de gerenciamento de vendas foi criado. Na fase de implementação, os funcionários não quiseram usá-lo e continuaram emitindo todas as faturas manualmente. O diretor da empresa emitiu uma ordem interna: as faturas emitidas e pagas fora do sistema não serão levadas em consideração ao calcular o prêmio do vendedor. O sistema foi implementado em 3 (!) Dias! Sim, esses três dias foram um inferno para o artista, um milhão de deficiências surgiram. Mas, embora eu pareça ser um "representante do artista", recomendo fortemente que você pense sobre essas formas de motivação.

Vou deixar a conversa sobre como organizar a operação do sistema na próxima vez. Mas observo que a manutenção do sistema após a implementação também requer um acordo , de preferência com o desenvolvedor. Este é um tipo de contrato separado que deve determinar como entrar em contato com o desenvolvedor se forem encontrados erros e as regras de comportamento com o desenvolvedor se algum processo for alterado (ou se um novo aparecer). Ou seja, o contrato prescreve como corrigir erros e como você planeja desenvolver o sistema juntos. Esse tipo de contrato é chamado de SLA (Service Level Agreement). Eu enfatizo que este é um acordo separado.

Algumas palavras sobre o custo e o timing

A TI usa uma abordagem universal para determinar o custo do trabalho, o chamado método de recurso. Estima-se qual equipe de especialistas, em que período implementa o conjunto de funções necessário. : (, ) 1 , 1 -, 1 , 2-3 , 1 «» . 3 . (, ) . . ? -, . hh. , , , …
Lembre-se: nenhum contratado será capaz de responder na primeira reunião quanto custa o sistema até que lhe digam quais processos devem ser automatizados. Ele pode avaliar apenas aproximadamente. Como você.



Se você aprendeu a receita para um projeto de TI, os resultados o surpreenderão.
Obrigado a todos!