estratégia de IA
Consultoria de IA que termina com dois ou três casos que valem a construção
O conselho pediu IA, dois pilotos não subiram e toda apresentação de fornecedor diz a mesma coisa com uma fonte diferente. Passamos dez dias medindo quanto o trabalho custa hoje, selecionamos os pontos em que um modelo muda esse número e dizemos, para cada um, se é caso de construir ou de comprar. Você termina com um memorando que os seus próprios engenheiros podem contestar e uma entrega escopada, com data e preço em cima dela.
10 dias, a maior parte deles medindo o que acontece hoje
A comparação de fornecedores está riscada de propósito: uma lista de ferramentas sem linha de base leva a discussão para outra reunião em vez de encerrá-la.
Ambição
Um mandato do conselho, pilotos que nunca subiram, dados que ninguém rotulou.
- board asks for AIno target
- pilotsnever shipped
- dataunlabelled
- vendor deckscompared
Lista curta
Dois ou três casos com os números de hoje, a decisão de construir ou comprar em cada um, uma entrega escopada.
- shortlist2–3 use cases
- baselinemeasured today
- build/buy callper case
- first deliveryscoped
10 dias, a maior parte deles medindo o que acontece hoje
Como o trabalho anda
- 01dias 1–2
Achar para onde vão os minutos e o dinheiro
Entrevistas mais tudo o que puder ser contado: volume de chamados, tempo de tratamento, taxa de erro, retrabalho. Metade do valor deste passo é que os números costumam ser novidade internamente.
- 02dias 2–4
Ordenar candidatos pela verificabilidade
Um caso com resposta certa registrada pode ser avaliado. Um sem isso vira questão de opinião no momento em que sobe, então desce para o fim da lista por melhor que soe na sala.
- 03dias 4–7
Construir ou comprar, caso a caso
Para cada caso selecionado: quanto custa um produto, quanto custa construir, o que fica com você depois. Vivemos de construir software, então nos obrigamos a nomear pelo menos um caso em que comprar vence.
- 04dias 7–10
Escopar a primeira entrega
Um caso, com conjunto de avaliação, linha de base, data e preço. Pequeno o bastante para o fracasso ser sobrevivível, real o bastante para o sucesso provar algo a quem aprovou o orçamento.
O que a plataforma faz e o que uma pessoa faz
| O que a plataforma faz e o que uma pessoa faz | Quem faz | Notas |
|---|---|---|
| Ler os seus sistemas para avaliar viabilidade | Plataforma | Que dados existem, onde estão e se dá para alcançá-los de onde o trabalho acontece. |
| Medir a linha de base | Os dois | A extração é mecânica. Combinar o que conta como erro é uma conversa com quem faz o serviço. |
| Ordenar os candidatos | Engenheiro | Pela possibilidade de verificar o resultado depois que ele sobe. |
| A decisão de construir ou comprar | Engenheiro | Julgamento, com o nosso conflito de interesse declarado no mesmo parágrafo da recomendação. |
| Prontidão dos dados | Os dois | A plataforma relata o que existe. Uma pessoa estima quanto vai custar deixar aquilo utilizável. |
| O memorando | Engenheiro | De quatro a oito páginas, escritas para os seus engenheiros discutirem com elas. |
Por que a recomendação vale dez dias
Somos nós que depois construímos a coisa, e dezenas de migrações e mais de dez anos de trabalho em legado estão atrás de cada recomendação do memorando. A estimativa que está lá é uma pela qual vamos ter de responder depois, não uma faixa copiada de relatório de analista. Quando dizemos que um caso é uma construção de vinte dias, é porque já construímos um.
Pegue os dois primeiros dias como peça isolada, se quiser um começo menor. Se a linha de base com que voltarmos não contar nada que você já não soubesse sobre a sua operação, você gastou dois dias em vez de um trimestre.
Perguntas que engenheiros fazem
- Vocês constroem coisas. Como a recomendação de vocês não é venda?
- Ele não é neutro e não afirmamos que seja. O que fazemos é declarar o conflito no memorando, nomear pelo menos um caso em que comprar vence construir e precificar a primeira entrega separadamente, para que o memorando valha a pena ser levado a outra pessoa.
- Precisamos de uma plataforma de dados antes de tudo isso?
- Normalmente menos do que disseram a você. A maioria dos primeiros casos precisa de alguns anos de registros e de um jeito de lê-los, não de um programa de data warehouse. Um programa de data warehouse é uma forma confiável de gastar um ano e meio antes de descobrir se o caso funciona.
- Nossos pilotos morrem depois da demo. Por quê?
- Quase sempre porque ninguém definiu o que é correto antes de construir, então o piloto não pode ser avaliado e não tem rota para produção. O passo dois existe para isso não acontecer uma terceira vez.
- Em que isso difere do diagnóstico de vocês?
- O diagnóstico lê uma base de código e planeja uma reescrita. Este lê um processo de negócio e decide se um modelo ajuda. Empresas com um sistema antigo e um mandato de IA costumam precisar dos dois, normalmente nessa ordem, e a gente roda um atrás do outro.
- De quem vocês precisam do nosso lado?
- Alguém que seja dono do processo e alguém que possa aprovar orçamento, cerca de três horas cada. Isto não é workshop e não precisamos da sua liderança inteira numa sala.
Pergunte por onde começar
Duas coisas nos põem em movimento: o que a diretoria pediu de fato e que processos consomem mais horas. Voltamos com o que a revisão cobre e quanto ela custa.
Um engenheiro responde, normalmente perguntando o que vocês já conseguem medir.