0. Mapa conceptual do caso



Baixar 15.27 Kb.
Encontro30.07.2016
Tamanho15.27 Kb.

Alameda SIE-2006-CASOI-NUMERO

SIE 2006

Caso I: JP Morgan's Take on IT Project Management

Observações de Correcção

0. Mapa conceptual do caso


Notou-se um esforço para um uso mais adequado dos mapas conceptuais. É de felicitar os alunos pelos progressos em termos gerais. No entanto resistem ainda várias “ilhas de ignorância” devido provavelmente a não terem dado atenção aos meus alertas sobre este assunto…

1. Que problema foi identificado por Marcia Bateson no banco JP Morgan que a levou a decidir lançar o projecto SAIL? Descreva o problema preferencialmente em termos genéricos e conceptuais, usando terminologia concreta do corpo de conhecimento da cadeira, em detrimento da repetição de factos específicos que já estão referidos na descrição do caso.


Claramente, os problemas eram de falta de eficiência na execução dos processos de negócio em face ao potencial da tecnologia.

Alguns alunos referiram haver um uso incorrecto da tecnologia. É preciso ter cuidado com afirmações deste género, pois temos de ter a noção de que a tecnologia evolui com o tempo. Assim, aquilo que num dado momento nos pode parecer incorrecto poderá tratar-se na realidade de uma prática que em devida altura terá sido mesmo a mais correcta, e que apenas num momento posterior se identifica como ineficaz face ao potencial da tecnologia nesse momento (podemos imaginar como seriam executados os processos antes de a JP Morgan poder usar folhas de cálculo e aceder em linha à informação da Bloomberg…).

Assim, numa perspectiva de uma empresa como sendo composta por organização+processos+dados+tecnologia, os problemas da JP Morgan residiam essencialmente num desalinhamento entre os processos e tecnologia, com potenciais consequências negativas na qualidade dos dados e com riscos para o controlo dos processos (record-keeping) e ainda problemas de fraca eficiência dos processos devido ao fraco suporte tecnológico aos mesmos. Não são descritos problemas de organização nem dos processos em si).

Finalmente, são completamente desadequadas as observações de alguns alunos referindo ter sido o problema provocado pela falta de visão e de investimento da JP Morgan em tecnologia. Sabe ler História (com “H”) é importante, e neste caso é disso que se trata! O caso descreve um cenário que teve origem em Janeiro de 1999, com a fusão de duas empresas, tendo a Marcia Beteson começado a trabalhar em Novembro de 1999, sendo ainda os resultados reportados relativos a Setembro de 2001. Atendendo a estes dados, este caso pode ser mesmo considerado um caso exemplar de sucesso em termos de análise de necessidades e de acção pela parte da administração da JP Morgan (começando pela visão em contratar uma CFO com as características da Marcia Beteson, que não só identificou os problemas, como desenhou a melhor metodologia para os resolver). Os alunos não devem por isso ser excessivamente influenciados pela sua juventude relativa e pelo pressuposto de que a informatização dos negócios e o alinhamento processos/tecnologia é uma coisa inerente a qualquer realidade e em qualquer momento… De certeza que chegará o dia em que qualquer grande parte dos negócios a totalidade da tecnologia actual serão eles mesmos também obsoletos (e nem toda a gente vai conseguir perceber isso da mesma maneira e com a mesma clarividência).


2. Que metodologia foi adoptada para a gestão do projecto SAIL? Porquê?


A descrição do caso não torna óbvia a sua associação a uma metodologia única, pelo menos seguindo as metodologias sugeridas pelo livro de referência. A correcção desta pergunta levou assim em consideração todas as respostas que se apresentaram como relevantes e com fundamentação coerente.

Tomando como referência as metodologias sugeridas pelo livro, teremos:

- “Ciclo de vida” tradicional: a descrição do caso torna aceitável que se identifique esta metodologia como tendo sido utilizada, embora de uma forma mais flexível que o habitual devido à divisão da solução em vários subsistemas (que eventualmente terão na prática conduzido a vários projectos). Por este motivo era importante enquadrar esta aproximação com alguma referência à metodologia JAD.

- Prototipagem: embora a sua referência não seja explícita, é adequado deduzir neste caso o uso desta metodologia, especialmente divisão do problema em aplicações e ao facto de se referir ter sido atribuída a responsabilidade de cada uma delas a equipas envolvendo analistas, programadores e clientes. Referências a metodologias RAD neste contexto serão ainda aceitáveis.

- “Packages” de software: este foi claramente um projecto “à medida”, pelo que qualquer referência a esta aproximação ao problema será desadequada.

- Desenvolvimento pelo cliente: apesar de ter sido um projecto à medida, o seu desenvolvimento foi coordenado e controlado num único contexto (o projecto SAIL), pelo que qualquer referência a esta aproximação também não estará correcta.

- Outsourcing: O texto refere claramente que esta aproximação foi seguida, no entanto é de esperar que os alunos a enquadrem adequadamente referindo que tal ocorreu essencialmente para as tarefas de desenvolvimento e de concretização. Veja-se por exemplo o uso do termo “helped” quando se descrevem os papéis desempenhados pela Trigyn e Syncata.

De realçar ainda, como factor importante na estratégia de desenvolvimento deste projecto, a preferência dada a empresas em que a própria JP Morgan tinha interesses como accionista (sendo por isso de certa forma donos). Isto representa uma relação mais estreita do que um simples outsourcing, representando em termos tácticos um princípio muito interessante.

Foi muito preocupante encontrar respostas indicando ter sido seguida uma metodologia Orientada a Objectos! Nada na descrição do caso faz referência a isso, o que indica ainda que os alunos que isso responderam não têm uma noção clara do que significa o conceito “Object Oriented”. Recomenda-se rever isso, por favor!!!

3. Como caracteriza os exemplos concretos resultados descritos no caso em relação às formas mais comuns de caracterizar os processos de mudança (Mudança de Paradigma; Reengenharia; Racionalização e Automação).


O processo de mudança descrito no caso representa claramente um exemplo de Automação (o termo “automate” é mesmo usado várias vezes no texto) e Racionalização (como no caso do exemplo da centralização dos dados e da normalização dos terminais de acesso).

A descrição oferecida não permite classificar o caso como um exemplo concreto de Reengenharia, já que os processos de negócio não foram postos com causa, mas apenas a forma como eram executados (com pouca automação, como no caso das actividades que implicavam reutilizar os dados da Bloomberg). Pode-se no entanto abrir uma excepção desta análise com, por exemplo, a referência à eliminação do envio duas vezes por ano de laptops para os escritórios locais (não se pode considerar ainda assim esta alteração como um caso claro de reengenharia, pois nada mais se diz sobre o processo em si, pelo que o mesmo pode muito bem ter continuado a se executado em todos os outros aspectos da mesma forma, facto que dessa forma deveria ser caracterizado por apenas uma automação de uma parte de um processo – distribuição de informação - que estava apenas parcialmente automatizado).

O caso também não será um exemplo de Mudança de Paradigma, pois não foi levantando nenhum ponto relativamente à natureza do negócio ou da organização.

Alguns alunos referiram ter tido a JP Morgan como objectivo neste projecto atingir um patamar “Six Sigma” (enquadrando isso mesmo num cenário de Reengenharia). Tal não é correcto, pois tal só terá acontecido na JP Morgan após este projecto. Tal pode ser confirmado lendo com maior cuidado as próprias fontes complementares fornecidas pelos alunos (um esforço apesar de tudo meritório).


4. Aprendizagem proporcionada por este caso


Na análise destas respostas valoriza-se como regra geral o alinhamento das mesmas com a matéria do capítulo. É uma boa oportunidade (geralmente pouco explorada)) para os alunos que buscam nota A marcarem assim a sua diferença positiva…

Notas finais


A maioria das classificações negativas (respostas abaixo do esperado) estão associadas ao uso impreciso ou incorrecto de conceitos e termos importantes que seria de esperar já não fosse problemático para os alunos nesta altura, tais como “mudança de paradigma”, “estrutura organizacional”, “processo de negócio” (o abuso e uso incorrecto deste termo em concreto é preocupante), etc.

É especialmente elevado o número de alunos que confunde os conceitos relacionados com um problema de execução ineficiente de um “processo de negócio” (mas não forçosamente mal definido ou ineficaz) com um “problema da estrutura organizacional” (cujo contexto tem a ver com a estrutura orgânica da empresa, relações de responsabilidade, autoridade, subordinação, etc.).



Sobre o conceito de “mudança de paradigma”, ao contrário do que vários alunos parecem dar a entender, isso não é algo que normalmente se pode ou deve decidir arriscar aplicar ou não em qualquer momento, mas sim algo que deve ser ponderado APENAS quando algo de anormal o justifique. De facto, o “paradigma” está associado à própria natureza, objectivos e contexto do negócio, pelo que só análises a este nível são relevantes para qualquer mudança associada.


30-07-2016 3:23


©principo.org 2016
enviar mensagem

    Página principal