O que e Governanca de TI – A Sua Origem, Historia, Conceitos e Fundamentos Basicos – Parte 1 agosto 20, 2011 por Aghatha Maxi Consulting

O QUE É GOVERNANÇA  DE TI ?

A Sua Origem, História,  Conceitos e Fundamentos Básicos – Parte 1.

O que é Governança de TI ? – A Sua Orígem,  História, Conceitos e
Fundamentos Básicos – Parte 1.

1 – Introdução, Histórico e Conceitos.

1.1 – Introdução / Histórico.

 A Governança em TI ainda é um assunto bastante controverso e pouco entendido de forma geral pelos Gestores ou “Governantes” e na maioria das vezes o assunto é abordado de forma muito ampla ou superficial e não é raro observarmos abordagens equivocadas daquilo que se julgaria ser de fato Governança e ainda o que vem a ser de fato Governança de TI.

 Com o objetivo de auxiliar os colegas e gestores das empresas que necessitam dispender algum esforço em futuro próximo em direção a Governança em suas organizações,  resolvemos escrever este artigo, compartilhando algumas experiências e conhecimentos adquiridos ao longo dos últimos oito anos de atuação neste segmento de consultoria.

 É necessário prevenir ao nosso leitor que o tema Governança de TI é bastante amplo e dependendo das condições preexistentes na organização e da abordagem utilizada para a adoção dos critérios da Governança, a missão poderá ser mais ou menos complexa e ainda irá requer mais ou menos investimento e esforço para ser de fato atingida.

 Primeiramente, é necessário entendermos a origem da “Governança” e quais são os seus reais motivos e objetivos. Explicar a as razões da Governança de TI através da sua relação com a Governança Corporativa,  embora seja a “forma acadêmica” correta, enquanto “abordagem em si”,  não é de todo suficiente para exprimir todos os objetivos a serem tratados e atingidos,  e mais ainda,  não esclarece qual deve ser o papel do “Governante”  antes, durante e depois de  obter a condição de “Governança”, principalmente quando o assunto é relacionado ao uso e gestão da tecnologia da informação.

• O Conceito “Puro” de Governança.

O conceito “puro” de governança não nasceu em 2002, com a aprovação da Lei Sarbanes-Oxley pelo Governo Norte Americano, ou seja, não foi o congresso deste país que inventou o conceito de Governança (Há colegas que acreditam que isto seja uma verdade, e que a “culpa” destas obrigatoriedades tenha  sido originado pelos políticos norte americano, o que obviamente não é verdade). O conceito de Governança é muito antigo e tem a sua origem nas primeiras organizações politicas e democráticas  nas  cidades-estados da Grécia Antiga (500 AC a 300 AC).

O Termo  “Governança” tem origem na palavra “Governo” e representa em sua essência o “Ato de Governar”, mesmo na Grécia antiga, era exigido do “Governante” certa “conduta” durante o exercício do “poder público” e relacionado aos “Atos” praticados pelo “Governante” durante o seu “Governo”,  sendo requerida pelos “eleitores”  uma conduta baseada em “valores” tais como: “Coerência”, “Transparência”, “Responsabilidade”, “Respeito”, “Ética” em relação ao “Grupo ou coletividade” o qual o governante deveria “representar” através dos seus “atos”.

Enfim, praticar “tudo aquilo” que pudesse ser “julgado pelo bom senso de todos” como sendo um “bom governo”.

• O Conceito “moderno” de Governança.

Nos tempos atuais, o conceito “público” de governança permanece praticamente inalterado, mudando apenas as formas adotadas pelos governantes para a identificação das “necessidades” dos seus “eleitores” ou “representados” em razão do aumento significativo da quantidade de “eleitores”, e das formas adotadas para comunicar aos mesmos os seus “valores” e o “resultado” obtido pelo seu “governo”, sendo isto denominado “transparência” das ações realizadas, e visam basicamente obter “aprovação” dos “eleitores” dos atos praticados pelo  “governante” em seu “governo”.

Na Grécia antiga, bastavam os Governantes se deslocarem até a praça central e com alguma competência em oratória, quaisquer questões existentes entre  “governo” e “eleitores” poderiam ser de pronto resolvidas.

Nos dias atuais isto se tornou uma prática impossível de ser realizada “pessoalmente”, o que justifica aos “governantes” apoiarem-se nos meios de comunicação para promover a “transparência” dos atos e fatos.

• O Conceito “organizacional” da Governança.

 Deste ponto em diante, iniciamos o tratamento do que seja Governança no contexto anunciado como sendo o objetivo deste artigo.

• A Governança em Empresas onde o Dono é Único

 Uma organização, durante o período de tempo onde o  “proprietário” é o gestor único do seu negócio, em tese,  não há razão para aplicação dos princípios de  Governança, pois o “Único Dono” do negócio é o seu “único governante” e “ele próprio” por suas “ações”, “omissões”, “atos de empreendedorismo”  se  “auto constituiu” no exercício desta função.

  

• A Governança em Empresas onde há poucos Sócios / Investidores

A Partir do momento que o “único dono” recebe “sócios” ou “investidores”, surge automaticamente à necessidade de aplicar os princípios de “governança”, pois surge ai as funções de “governo”, uma vez que dentre os sócios  e investidores existentes, haverá sempre a condição de que “um” mais que os “outros”, seja denominado o “governante” da organização, ou ainda, o seu “gestor”.

Note que mesmo nesta relação, o “gestor” é “aceito” pelos demais “sócios”, materializando a  relação de “governança”, pois há um “governante” e também há  a figura dos seus “eleitores”.

Neste caso, os conceitos e atitudes requeridos historicamente aos “políticos” passam a ser  aplicáveis ao “gestor” da organização, agora não mais  se relacionando com “eleitores”, mas sim em relação aos  demais “sócios e/ou investidores” que o instituiram nesta função.

Como a dimensão do público aqui exposta ainda é reduzida (Quando há poucos Investidores),  o esforço praticado pelo “governante” é um pouco maior,  do que seria necessário ser praticado por um “governante” da Grécia antiga, ou seja, através da execução de algumas reuniões, atas, e comunicados, todas  as questões de “governança” e “transparência” dos atos praticados em  sua “gestão” podem ser dadas como “satisfeitos”.

Neste caso, as questões de “transparência” dos atos de seu “governo”  ainda podem ser “comunicadas” e “avaliadas” com a “presença” de todos os “interessados”.

Pelo menos em “tese”,  as questões de “governo” podem ser resolvidas assim,  em organizações onde há incidência de poucos “sócios” e um “gestor” principal.

• A Governança em Empresas onde há Muitos Sócios / Investidores

A partir do momento que uma organização, inicialmente com apenas “um dono” ou com “poucos sócios” resolve  “abrir” o seu “capital”, ou seja, transforma as “cotas capitais” em “ações”, e estas por sua vez, passam a serem disponibilizadas para “negociação” junto ao mercado de capitais, estas empresas passam a ser “acometidas” em termos de “governança” pelas mesmas “dificuldades” enfrentadas  pelos “políticos modernos” em razão da grande quantidade de  “eleitores”, só que agora estes “interessados” passam a ser “todos os acionistas” da organização (Aqueles que detêm ações), no entanto, um “gestor” de uma grande corporação não tem a possibilidade de utilizar-se de um canal de TV aberto ou dos meios de comunicação em massa  para comunicar e resolver ali as suas questões de “governo” e dar conta da “transparência” de suas ações,  frente ao publico em geral, uma vez que as “organizações” possuem caráter “privado”, e estas questões só dizem a respeito apenas a uma “parcela” do publico em geral composta apenas pelos seus “investidores”.

Então o nosso leitor poderá se perguntar: Se os assuntos de “governo”  de uma organização são tratados de forma “privada” ou “reservada”. Como então estas organizações atraem novos investidores?

Em resposta a esta dúvida, há ainda que explanar sobre as questões legais, relacionadas às grandes empresas (Lei das Sociedades Anônimas), regras e atribuições impostas pelo Mercado de Capital (Novo Mercado/BOVESPA, SOX, BASEL), e cuja ênfase, estão relacionadas a estabelecer critérios e proteções para o investidor, visando  promover a sua “confiança” em relação às organizações, e este,  é o “fator determinante” que irá “atrair ou repelir” novos investidores para uma organização, ou seja, o foco passa a ser uma “questão de confiança”  e não o critério de “aceitação/aprovação” como é a dimensão enfatizada pela  “governança publica”,  tanto a antiga como na moderna.

Em razão desta “transparência” com o seu “publico investidor”,  que uma “organização de capital aberto” estabelece a sua relação de “confiança”  entre os seus “gestores” e seu “publico investidor”. Isto em essência é o que se denomina “Governança Corporativa”.

Este conceito, embora possa parecer recente, também é antigo e tem a sua origem na “Revolução Industrial”, quando as primeiras “oficinas” se transformar em  “pequenas fábricas” e estas,  após  receberem a  adesão de investidores e sócios veio a se transformar nas primeiras grandes organizações modernas, ai surgiu o conceito e a necessidade do “governante organizacional” e em sua consequência as ações de “governança”.

  

• A Relação da Governança de TI com a Governança Corporativa.

Em meados do Século passado surge a presença da informática, e com o uso desta ferramenta, as grandes corporações elevaram a sua “capacidade” de processar grandes volumes de operações, e este aumento,  acelerou o crescimento destas empresas e aumentando mais ainda a quantidade de investidores, promovido por décadas de operações e de crescimento constante.

No entanto, como todo o remédio tem o seu efeito colateral, o advento da “informatização” e do aumento “em ordem geométrica” das operações, surge um “Risco” que não havia antes, ou seja,  a “Possibilidade” de que uma “ação isolada” de alguém, em um determinado momento, alterar o conteúdo de um “número” para “mais ou para menos”, e modificar com isto o “resultado final” de uma organização em detrimento da ocorrência de  “fatos reais”  que o justifiquem.

Este tipo de ação “fraudulenta”, uma vez de conhecida  pelo “publico” investidor, pode comprometer drasticamente a “confiabilidade”  que os investidores possuem pela empresa em questão, desvalorizando o “valor” de suas ações no mercado de capitais, e com isto,  prejudicando seriamente a todos os seus investidores.

Pois fatos desta natureza de fato ocorreram, envolvendo algumas empresas americanas entre os anos de 2001 e 2002, foram descobertos e após serem comunicados ao público daquele país, acabou por prejudicar as “economias pessoais” de uma grande quantidade de investidores americanos. Visando a proteção do mercado de capitais e de seus investidores, surgiu em Junho de 2002 a Lei Sarbanes-Oxley,  estabelecendo o “conceito” atual de “Governança Corporativa” e em consequência da participação e importância da “informática” nas operações das organizações, surge também a “Governança de TI”, visando exclusivamente estabelecer mecanismos de proteção, segurança, confiabilidade nas empresas e com isto evitar a ocorrência de fraudes, viabilizar meios para a sua identificação e com isto,  proteger o mercado investidor americano, e demais investidores que atuam naquele pais.

É um fato pouco conhecido como os legisladores americanos chegaram a este “formato” de exigências a serem satisfeitas pelas empresas. Após os escândalos financeiros de 2001/02, os legisladores perceberam que havia algumas empresas, mesmo em detrimento dos eventos  ocorridos no mercado de capitais, continuavam apresentando um alto índice de “confiança” pelos  seus “investidores”, e posteriormente,  visitando cada uma destas empresas,  notaram que elas possuíam em comum a adoção de modelos de gestão baseados em regras de “governo”, controle de condutas administrativas, contábeis e dos processos de qualidade relacionados ao uso da tecnologia e operações embasadas em  “documentos e processos formais que incluíam o uso de melhores práticas sugeridas por diversos padrões de qualidade entre eles: “ISO – International Organization for Standardization e BS- British Standards Institution ” e praticavam ainda uma relação  de “transparência” e  forma “regular” com os seus investidores.

Com base nestas constatações e na inclusão da “responsabilização criminal pela ocorrência de fraudes” a que os gestores passariam responder, foram criadas às bases dos requisitos de Governança que foram instituídos através da Lei Sarbanes-Oxley. O conteúdo da lei em si não proporciona todo o seu conteúdo, pois ela o faz com o auxilio de instruções complementares emitidas por instituições regulatórias (Self-Regulatory Organization- SRO) as quais são instituídas e apoiadas pelo Governo Americano,  tais como: PCAOB – Public  Company Accounting Oversight Board e  ISACA- Information Systems Audit and Control Association,  e que juntas deram origem a base aos requisitos daquilo que denominamos “Melhores Práticas” aplicáveis em Governança e Governança de TI respectivamente.

1.2 – O Início da Governança no Brasil

A Governança Corporativa e a Governança de TI  passam a integrar como “necessidade real” para os Gestores de TI brasileiros, somente dois anos após a aprovação da Lei Sarbanes Oxley pelo Congresso Norte Americano,  visto que nos dois primeiros anos de aplicação desta lei (2002-2003), o  foco inicial era o processos de Compliance das empresas americanas sediadas no território americano, fazendo com que a “onda de Compliance”  chegasse para valer ao Brasil apenas em meados de 2004 e que perdurou fortemente até o final de 2006 (Limite para Conclusão de Compliance SOX).

Neste período, o foco das certificações passaram a ser subsidiarias e filiais das empresas norte americanas sediadas fora do território americano e incluindo algumas poucas empresas brasileiras, que nesta mesma época,  mantinham suas ações na Bolsa de Valores de Nova York (NYSE).

Desta época aos dias de hoje, diversas empresas que inicialmente não figuravam nesta pequena e seleta lista, buscou atender aos requisitos e certificações necessárias e obtiveram  o “direito”  de incluir as suas ações na bolsa de valores norte americana.

Para quem “não é do meio”, isto pode parecer algo “sem sentido”, mas certamente o é:

Para exemplificar a mudança promovida por este “Compliance”, seria mais ou menos em “termos de comparação” a  um fornecedor que vende o seu produto apenas para um “mercado” nas proximidades da sede de sua fábrica e de uma hora para outra, passa e estender as suas vendas para uma grande rede de “supermercados” presentes em todo o país.

Este “aumento”  na presença no mercado e consequentemente do aumento do volume de vendas apresentado pelo “produto”  é comparável  ao  possível impacto causado quando uma “ação” passa a ser comercializada na bolsa de valores  Norte Americana,  e as consequências disto para a empresa são extremamente positivas, pois há um aumento sensível no volume de vendas das suas  “ações” e também do “aporte de recursos” quando este direito é alcançado.

Nesta mesma época (entre 2001/2006),  diversas bolsas de valores pelo mundo afora acabaram criando regras de proteção aos seus  mercados de acionistas, seguindo os mesmos moldes adotados pela NYSE , e no Brasil não foi diferente, e ainda em 2001, iniciamos a adoção de critérios  baseados em “Governança Corporativa”, através da adoção de regras estabelecidas pela CVM- Comissão de Valores Mobiliários e BOVESPA, onde a adesão das empresas,  continua sendo voluntária aos critérios de “Governança Corporativa”, podendo ainda receber classificações de Nível 1 e Nível 2 (Mercado Novo / Bovespa) de acordo com o seu nível de adesão.

Nos critérios de Governança Corporativa estabelecida pelo Nível 2 – Mercado Novo/BOVESPA, a Governança de TI, é tratada de forma “indireta” e através das “verificações” de auditoria aplicadas aos controles internos operacionais e financeiros  nas empresas e realizados com base e referencia as  “melhores práticas de mercado”, quando observadas pelas Auditorias, onde a  ênfase está direcionada a verificação dos riscos e efetividade dos controles internos (Quando menciona o atendimento de “conformidade”  e nos remete as  “melhores práticas de Mercado”, indiretamente nos remete  as “melhores práticas” aplicáveis a Governança de TI, e que são  estabelecidas pela SOX e regradas de acordo com os critérios de auditorias indicados pelo  ISACA e PCAOB.

Embora o nível de exigência aplicado no Brasil não seja o mesmo (é Mais flexível), os critérios de uma “forma geral” utilizados durante a “identificação” e “mitigação” dos riscos seguem a mesma lógica e práticas adotadas pela Governança de TI  norte americanos.

1.3 – Os Novos Paradigmas da Governança no Brasil

Pense um pouco comigo, e veja se o conteúdo do paragrafo a seguir representa ou não uma “realidade muito possível” a médio e longo prazo em nosso país:

“No ritmo que as empresas brasileiras estão crescendo, mais dia ou em menos dia, ela penderá para a abertura do seu capital e visando disponibilizar as suas ações para ser negociada na Bolsa de Valores, isto é algo inevitável e representa a única forma de uma empresa de “médio” ou  “médio-grande” porte se capitalizar e tornar-se uma empresa de “grande-porte” em  toda a sua plenitude.

E,  mesmo que a empresa onde atuamos seja uma empresa “familiar”, mesmo para elas,  este dia vai chegar, caso isto não ocorra de fato, estas empresas estão “fadadas” a permanecerem nos patamares atuais ou crescerão em ritmo mais lento, passando a correr o risco de que em algum dia, uma empresa pertencente ao “ grupo principal” venha a lhes adquirir ou venha a ocupar a sua parcela e lugar no mercado. “Infelizmente o mundo é assim mesmo, se não avançarmos rapidamente o “leão” vem e nos consome”.

Entenderá com mais propriedade o conteúdo desta frase, aquele que em alguma vez em sua vida teve a oportunidade de realizar um “salto com paraquedas”. Não é uma decisão fácil, mas será de fato “um paraquedista”, somente aquele que, efetivamente “realizar o salto”. “Para aqueles que “não saltaram” o voo foi apenas um passeio panorâmico, com uma mochila diferente atada as costas”.

Ou Ainda, se a empresa onde atuamos já possui ações negociadas na bolsa de valores em nosso país e obteve com isto um nível de crescimento que a tornou maior do que era inicialmente, é inevitável que em algum dia estas ações passem a ser negociadas em alguma das principais bolsas de valores espalhadas pelo mundo. Esta é a única forma de uma “grande-empresa nacional” vir a tornar-se uma multinacional global e hastear a nossa bandeira em mastros espalhados mundo afora.

Nada disto é, ou poderá ser possível, sem que as questões de Governança Corporativa e as relacionadas à Governança de TI estejam resolvidas e que os controles e métodos envolvidos estejam em pleno uso e funcionamento.”

Se a base  aplicada nesta linha de raciocínio te faz algum sentido e de alguma forma,  você leitor,  concorda com estes argumentos, você está mesmo “fadado” a vir a conhecer a aprofundar-se em “assuntos” relacionados a Governança.

Vamos pensar um pouco mais adiante: Se você esta no início de sua carreira (seja ela relacionada  às ciências de tecnologia ou a administração de empresas em geral), e  pretende vir a ocupar as posições de CIO ou CEO em grandes corporações daqui a  20 ou 30 anos, este é irremediavelmente o seu caminho a ser seguido,  comece a trilha-lo ainda hoje,  ou quem ocupará  esta vaga lá no futuro,  possivelmente será algum “profissional treinee” em  fase de treinamento neste assunto nos dias atuais.

Foi com base nesta lógica e visão deste futuro que criamos o Instituto Hermann Haan e instituímos o projeto IH2, destinado a formar consultores capazes hoje, para que possam vir a se transformar em gestores capacitados e globalizados no futuro.

Mesmo tendo atuado na organização de processos e controles organizacionais e, na organização de processos relacionados a TI durante mais de 25 anos,  confesso que  no início o entendimento e aplicação destes conceitos nos foi um pouco “confuso”, pois as abordagens utilizadas pelos diversos institutos e organizações envolvidas ou inseridas no contexto da  Governança nos parecia ser desconexas e muitas vezes sem sentido, quando analisadas de forma conjunta e integradas entre si, e infelizmente posso lhes garantir que em verdade é assim mesmo. Esta primeira “impressão” causada pelos “conceitos e aplicação” de tudo aquilo que seja relacionado à “governança” aos  “leigos” promove, e acreditamos que continuará a promover durante muito tempo ainda,  muita confusão, tentativas frustradas e uma sucessão infindável de erros de aplicação e integração dos diversos conceitos e práticas envolvidas.

A bem da verdade, cada instituição promove a sua “área de foco” ou “especialidade”, e cada qual,  dentro do limite estabelecido pelo universo contido em seu “quadrado”, promovem da melhor forma possível aquela “parcela” do conjunto de “conhecimentos e práticas” daquilo que denominamos ser governança de TI.  E, o grande “segredo” de tudo isto está relacionado à adoção de modelos que possam integrar e fazer interagir as diversas áreas do conhecimento envolvidas, para que tenhamos como produto final, aquilo que se denomina “Governança Funcional de  TI”.

1.4 – Componentes Principais da Governança de TI.

Vamos inserir aqui uma figura, colocando os principais modelos e recomendações, que juntos, proporcionam um “razoável” grau de cobertura  e  maturidade  em  Governança,  para que o nosso leitor possa perceber a dimensão geral do tema em questão:

 

Embora a figura represente um “organograma”, nos aludindo certa relação de “hierarquia” e “relação de dependência” entre os diversos “modelos” e “melhores práticas”, esta alusão não é de todo correta, embora exista de fato está “relação”, ela é absolutamente relativa quando passamos do campo teórico para o campo prático das relações entre os diversos processos e disciplinas que o compõe.

1.5– Erros comuns causados pela Unitarização dos Componentes da Governança de TI

O erro mais comum aplicado no entendimento e aplicação das disciplinas contidas em cada um dos componentes listados nesta figura e muitas outras variações publicadas mundo afora, é  acreditar que colocá-las em ordem unitária em um plano de ação  (To-do-list) e priorizar uma sequencia para a sua aplicação e então adotá-las  e ainda, que ao final desta  “jornada”,  o “assunto” governança estará resolvido,  Quem pensa assim,  sugerimos repensar imediatamente os seus conceitos, pois embora esta seja uma “abordagem possível”, é também aquela que representa o principal motivo pelo qual a adoção da  “Governança” seja tão dispendiosa, traumática e tão complexa para as empresas.

Vou lhes citar um exemplo, que pode nos representar isto que lhes afirmo, em relação ao volume de investimentos e das inúmeras “rodadas” de “tentativas e erros” que são necessárias muitas vezes para adotar uma melhor prática exigida pela Governança. Vamos citar aqui apenas um,  mas que geralmente é o “mais comum” é o mais “representativo” , e é o que mais facilmente pode ser percebido e entendido.

Exemplo:

Imaginemos que a nossa empresa “fictícia”,  necessita adotar uma “Metodologia”  para manter as suas iniciativas de mudanças em “projetos” sob controle, e com isto, atender aos requisitos estabelecidos pela Governança TI em relação a mudanças e projetos.  (Veja PO10 e AI6 – COBIT 4.1).

Por cinco minutos, vamos “fazer de conta” que a figura contida no gráfico acima citado “não existe ou ainda não seja conhecido por completo”, e sendo assim, “seria razoavelmente correto” imaginar que ao contratar alguém ou você mesmo compor uma metodologia para gerir os seus projetos de “desenvolvimento de sistemas” seria o “suficiente” para considerar o assunto “Gerenciamento de Projetos e mudanças” por concluído e atendido.

Em primeira análise, esta “missão” seria uma atividade razoavelmente “simples”, bastaria alocar alguns de nossos melhores analistas de sistemas, e determinarmos a eles que definam um modelo de trabalho “metodologia” se possível obtendo um “consenso” com os demais analistas de sistemas e programadores da companhia, e era isto, Em pouco tempo, teremos um “método” em uso para promover as mudanças e os projetos de desenvolvimento de sistemas na companhia.

No entanto, se trouxermos o “conteúdo contido em nossa figura” de volta a vida, e repassar cada quadro com um pouco mais de “critério”, facilmente poderemos perceber que  um “projeto”  que se propõe a  “desenvolver ou modificar  um sistema”,  possa ter algum tipo de “relação” e poderia muito bem “causar impactos” em quase “todos”  os quadros que compõem o referido organograma contido em nossa figura.

Vamos entender alguns relacionamentos possíveis, enumerando “uma pergunta” para cada “quadro”, considerando nela algumas “possíveis relações” entre a “disciplina” descrita em cada quadro com um “projeto/atividade” que se propõe a desenvolver/modificar um novo sistema:

• O controle de acesso a ser inserido no escopo de desenvolvimento do sistema/aplicação foi avaliado pela equipe de riscos e segurança, no momento de analisar os requisitos da nova aplicação?
• O desenvolvimento e testes, segregação entre as funções / perfis envolvidos na operação do sistema, alçadas e controles compensatórios, conflitos de interesse entre os usuários foram considerados como requisitos no escopo da nova aplicação?
• Os requisitos do sistema consideram somente as questões de negócio (solicitante) ou também são consideradas as questões de ordem técnicas de TI, tais como: Modelos de  arquitetura, padrões de infraestrutura e serviços de TI, padrões de analise e codificação segura de sistemas,  integrações com os demais sistemas?
• A Infraestrutura, serviços de apoio e suporte para a nova aplicação foram avaliadas durante o levantamento dos requisitos técnicos para o novo sistema?,  há recursos de TI capazes de absorver a nova aplicação sem causar impacto nas demais existentes?
• O método de engenharia de software contempla ações de governança em relação ao registro de requisitos, analise, construções, validações e testes,  responsabilidades pela implantação e suporte aos usuários do negócio? – Normalmente as metodologias somente atendem a este requisito.
• O projeto possui controles que possibilitam o seu gerenciamento durante todo o seu  ciclo de vida de desenvolvimento do software? – Normalmente é construída uma MDS para tratar as questões do ciclo de vida do software  e uma  MGP  atendendo as questões relacionadas ao ciclo de vida do Gerenciamento de projetos. Nestes casos, quando o projeto “não dá certo”,  não há formas de identificar claramente onde ocorreu a falha (Eis aqui a eterna discussão entre o PMO, GP , Analista de Sistemas, Programadores e Testadores, onde cada um fez exatamente a sua “cota parte”, mas o sistema não saiu conforme o combinado.).
• E Por último e não menos importante,  estão as questões de segurança e não vamos nos enganar acreditando que a segurança deve estar restrita apenas as questões de acesso, pois há ainda as questões de segurança física, redes, backup /restore, continuidade, contingencias, e tudo mais relacionado ao gerenciamento da segurança da informação.

E  para Concluir,  duas perguntas finais:

• Seria sensato incluir no ciclo de vida de desenvolvimento de sistemas,  “gatilhos” que pudessem atender e responder a estas questões  “durante” o ciclo de vida do projeto?

ou

• Faria mais sentido não incluir estes “gatilhos”  no contexto da metodologia e deixar para que todas as áreas impactadas  controlem estas “integrações”  de forma paralela a Metodologia Desenvolvimento do sistema?

Quando ocorre uma resposta não adequada para estas perguntas,  verificamos posteriormente a existência de alguns possíveis “vícios”,  mesmo depois de investirmos tempo e dinheiro no desenvolvimento de  metodologias continuamos não atingindo o resultado proposto pela Governança TI e consequentemente causando impactos desastrosos na Governança Corporativa,  no que tange as questões relacionadas a “manter projetos sob controle”, e dai verificam-se situações como as abaixo relacionadas:

• Sistemas sem controle de acessos, segregação de função, ou com controles falhos e incompletos.
• Sistema que criam novas situações de risco para a TI e ao negócio, fraudes, erros, inconsistência de dados, apurações incorretas de valores, etc.
• Sistemas, embora tecnicamente bem desenvolvidos, que não possuem os recursos de infraestrutura e serviços necessários para lhe oferecer o devido suporte, provocando paradas no negócio, perda performance, atrasos operacionais, incidentes recorrentes, etc.
• Sistemas que acarretam impacto no ambiente e performance em recursos destinados a suportar outros  sistemas pré-existentes (Funcionava bem no inicio, agora demora ou perdeu a performance de uma hora para outra sem nenhuma explicação ou motivo aparente),
• Projetos que demandam mais tempo para serem concluídos do que o inicialmente planejado, o software ficou pronto e a infraestrutura ainda não, faltam periféricos, instalações de rede até o ponto de utilização, etc.
• Projetos que demandas mais recursos do que os inicialmente previstos,
• Sistemas que apresentam falhas de engenharia de software ou de atendimento de escopo,  faltando ou sobrando requisitos em seu produto final,
• Sistemas confeccionados para os usuários, mas estes,  inexplicavelmente não o utilizam ou apoiam o uso do sistema,
• Sistemas sem documentação, sem rastreabilidade em seu processo de produção, quem mesmo foi o usuário que solicitou este sistema?
• Sistemas que após serem concluídos, demandam novas solicitações de desenvolvimento para então integra-los aos sistemas pré-existentes,
• E tantos outros vícios que poderiam ser aqui relacionados, cuja causa é a falta de  integração entre  a aplicação das melhores práticas com as demais melhores práticas de TI e que na grande maioria das vezes não tem nenhuma relação com aspectos de competência dos técnicos que construíram as soluções, mas sim os que definiram a amplitude dos seus métodos de trabalho (Aqui vale registrar a máxima de Albert Einstein, onde a “pergunta “certa” contém “metade” da resposta”, e a qual eu acrescentaria ainda um pequeno complemento: ”Quando a ”pergunta” ou a  ”resposta” é errada, teremos como resultado o ”dobro ou o triplo” do esforço que seria “realmente necessário” para obter a resposta “realmente certa”.)

Ai o nosso leitor poderá se perguntar, ou ainda continuar tendo dúvidas, relacionadas ao real motivo pelo qual devemos adotar “melhores práticas” em TI para o gerenciamento de projetos e mudanças e os motivos pelos quais estes métodos devem ser integrados a todos os
demais processos de TI.

A resposta é bastante “simples”,  quando inserimos a Tecnologia nas questões de governança, estamos endereçando com isto o “risco” atrelado as suas “operações” e incluindo nelas as atividades de  “desenvolvimento e manutenção” dos sistemas e consequentemente as informações que eles manipulam e armazenam (estas informações irão compor o resultado da empresa ao final do exercício contábil, e serão endereçadas e publicadas no seu Balanço).

Os fatos ocorridos em 2001/2002 ocorreram devido a “fraudes” relacionadas à “manipulação indevida” das informações das empresas.

O “ato” de “desenvolver ou modificar” sistemas esta relacionado diretamente as “informações”, seja através de “projetos ou atividades mudanças” aplicada em sistemas, e ainda, manter isto “sob controle” é um dos  “pontos chaves” da governança corporativa e Governança de TI,  pois interage diretamente na “relação” de Integridade, confiabilidade e disponibilidade das “informações”, e isto,  é à base da “confiabilidade” a que os “governantes”  devem “transparecer” para as partes  “interessadas” em seu “governo”, e, portanto, o resultado obtido pela sua gestão.

Fim Artigo.

—–

• Este artigo está disponível para download no formato de Documento (PDF) no seguinte endereço:  Http://www.aghatha.com.br/news.htm

—- Fim Conteúdo Artigo —-

Agradecimentos e Convites:

As informações e comentários existentes neste artigo são o fruto de observações e experiências adquiridas pelo autor durante a  execução de projetos ao longo de 30 anos de atuação no mercado. Utilizamos este espaço para a divulgação e intercâmbio destes conhecimentos junto aos nossos leitores, clientes e amigos.

Caso você tenha alguma dúvida ou necessidade de informações adicionais para o seu entendimento ou aplicação, entre em contato conosco através do e-mail abaixo.

Fonte TI Especialista Brasil - http://goo.gl/tvqcb

Resumo BABOK 2.0 Gerencia de Negócios

1.A análise de negócios 

"A Análise de Negócios é o conjunto de atividades e técnicas utilizadas para servir como ligação entre partes interessadas no intuído de compreender a estrutura, políticas e operações de uma organização e para recomendar soluções que permitam que a organização alcance suas metas." (BABOK 2.0)

A execução da Análise de Negócios foca na compreensão de como a organização funciona e alcança os seus propósitos e na definição de quais capacidades devem ser possuídas para que ela possa prover produtos e serviços que atendam aos seus clientes.

Este trabalho envolve o apoio à definição e compreensão das metas organizacionais, a compreensão de como essas metas são ligadas aos objetivos específicos, a determinação dos cursos de ação necessários para alcançar as metas e objetivos e por fim, a definição de como as diversas unidades organizacionais e partes interessadas dentro e fora daquela organização interagem.

Os esforços de Análise de Negócios podem ser empregados com o objetivo de compreender a situação atual de uma organização (corporação, unidade de negócio ou até mesmo departamento), conhecida como “AS IS” (como é), uma base para a posterior identificação da necessidade do negócio e da solução, que formará a visão “TO BE” (a ser).

Todavia a principal aplicação da Análise de Negócios é a definição e validação de soluções que atendam as necessidades do negócio, seus objetivos e metas.

 1.1.Histórico recente da análise de negócios

A Análise de Negócios, como outras importantes disciplinas organizacionais, como o gerenciamento de projetos, surgiu da prática cada vez mais comum das suas atividades e técnicas de forma consistente, agrupada e por determinados membros das organizações que passaram a se reconhecer como praticantes.

Um grupo de praticantes, auto denominados analistas de negócios criou em outubro de 2003 em Toronto, Canadá, o IIBA^ – International Institute of Business Analysis, o Instituto Internacional de Análise de Negócios. O IIBA^ destina-se a apoiar a emergente comunidade de Análise de Negócios através de iniciativas como a criação e desenvolvimento da consciência e reconhecimento do valor e da contribuição do Analista de Negócios, a definição do Corpo de Conhecimento de Análise de Negócios (BABOK^) e o reconhecimento público através de um programa de certificação com reconhecimento internacional.

O comitê responsável pela definição do Corpo de Conhecimento de Análise de Negócios (Business Analysis Body of Knowledge), conhecido como Guia BABOK^, foi formado em 2004 e definiu e esboçou o padrão global para a prática da Análise de Negócios que teve a sua primeira versão lançada em 2005, encontrando-se agora na segunda versão, lançada em 2009.

O Guia BABOK^ descreve as práticas geralmente aceitas no campo da Análise de Negócios, o seu conteúdo, também baseado em extensa revisão bibliográfica, passou por revisões feitas por praticantes, pesquisas junto à comunidade de Análise de Negócios e consultas feitas a renomados especialistas. As tarefas e técnicas descritas são utilizadas pela maioria dos praticantes de Análise de Negócios e podem ser aplicadas na maioria dos contextos onde ela é executada, na maior parte das vezes. Como qualquer outro conjunto de práticas, o conteúdo do Guia BABOK^ deve ser adaptado para condições específicas e não ser interpretado como uma imposição a respeito de como devem ser desempenhadas as atividades.

Institucionalmente, o IIBA^ vem recebendo reconhecimento crescente da comunidade e tem seus esforços potencializados pelos atuais 125 capítulos espalhados pelo mundo.

O Brasil possui atualmente um capítulo estruturado, o Capítulo São Paulo e mais dois capítulos em implantação, no Rio de Janeiro e em Brasília.

 1.2.Quem é o analista de negócios?

Os esforços do IIBA^ visam o reconhecimento do analista de negócios como um profissional de responsabilidades bem definidas, mas isso não quer dizer que para ser considerado membro da comunidade de praticantes seja necessário ter “Analista de Negócios” no seu cartão profissional, basta apenas, executar as atividades presentes no seu escopo.

Consultores, arquitetos do negócio, analistas de processos, gerentes de produtos, analistas de sistemas, product owners são exemplos de profissionais que executam tarefas do escopo da Análise de Negócios. Isso também ocorre com aqueles que desempenham disciplinas relacionadas com o Gerenciamento de Projetos, gestão da qualidade, desenvolvimento de software, e design de interação.

 1.3.principais Conceitos

1.3.1.Domínios

Na Análise de Negócios, um domínio corresponde à área específica da análise sendo realizada. Esta área pode corresponder a uma organização inteira, uma unidade organizacional, clientes, fornecedores ou mesmo a interação entre a organização e esses públicos.

 

1.3.2.Soluções

Para que a organização atenda uma necessidade do negócio, se beneficie de uma oportunidade ou resolva um problema é necessário um conjunto de mudanças em relação à sua situação atual. Este conjunto de mudanças é chamado de solução.

O escopo de uma solução tende a ser mais restrito do que o escopo do domínio no qual ela é implementada (uma mudança nas práticas comerciais de uma organização é mais restrita do que a sua área comercial em si).

O escopo da solução serve de base para a definição do escopo da iniciativa ou projeto destinado a implantá-la.

Cada solução é formada por diferentes componentes de soluções. Cada componente é um método de criação de uma capacidade requerida para que a solução tenha efeito.

Alguns exemplos de componentes de solução são processos de negócio remodelados, estrutura organizacional revisada, regras de negócio, terceirização, aplicações de software / sistemas de informação, redefinição de cargos, políticas comerciais e desenvolvimento de web sites.

No que tange às soluções, cabe à Análise de Negócios o auxílio para que a organização defina a solução ideal para as suas demandas. A solução ideal não consiste naquela que promete os melhores resultados, mas sim, daquela que além de atender as demandas, leva em conta todas as limitações (tempo, orçamento, regulamentos entre outros) sob as quais a organização opera.

 

1.3.3.Partes interessadas

Uma parte interessada é uma classe de pessoas afetadas pela iniciativa de forma direta ou indireta. As partes interessadas representam pessoas com as quais o analista de negócios irá provavelmente interagir de alguma maneira.

Classes comuns de partes interessadas envolvem o próprio analista de negócios, os clientes, o especialista no domínio do negócio, o usuário final da solução, o especialista na implementação da solução, o desenvolvedor ou engenheiro de software, profissionais de gerenciamento da mudança organizacional, arquitetos de sistemas, instrutores, profissionais de usabilidade, gerentes de projetos, testadores, agências reguladoras, o patrocinador da iniciativa e fornecedores.

 

1.3.4.Requisitos

Um requisito é:

“1. Uma condição ou capacidade necessária para uma parte interessada para resolver um problema ou atingir um objetivo.
2. Uma condição ou capacidade que deve ser alcançada ou possuída por uma solução ou componente de solução para satisfazer um contrato, padrão, especificação ou outros documentos formalmente impostos.
3. Uma representação documentada de uma condição ou capacidade como em (1) ou (2)” (IIBA, 2009, p.4)

Para efeitos de estudo da Análise de Negócios, o termo “requisito” é utilizado no seu sentido mais amplo, ou seja, “Requisitos incluem, mas não estão limitados a, condições ou capacidades futuras ou passadas em um empreendimento e descrições de estruturas organizacionais, papéis, processos, políticas, regras e sistemas de informações. Um requisito pode descrever o estado presente ou futuro de qualquer aspecto do empreendimento.” (IIBA, 2009, p. 5)

O sentido amplo adotado para o termo requisito implica a existência de requisitos de diferentes níveis, saídos de diferentes pontos de vista e níveis organizacionais.

No primeiro nível estão os requisitos do negócio que consistem em metas de nível mais alto, objetivos ou necessidades da organização. Esses requisitos descrevem a razão de ser da iniciativa em análise (ou em curso), seus objetivos e as métricas que serão utilizadas para medir o seu sucesso. Os requisitos do negócio alinham a iniciativa à estratégia corporativa e não às necessidades específicas de partes interessadas dentro dela. Os requisitos do negócio são desenvolvidos dentro da área de conhecimento Análise Corporativa.

No segundo nível estão os requisitos das partes interessadas que consistem nas necessidades específicas de todas as partes que possuem interesses em relação à iniciativa. Os requisitos das partes interessadas criam um vínculo entre os requisitos do negócio e os requisitos da solução. Os requisitos das partes interessadas são definidos na área de conhecimento Análise de Requisitos.

Os requisitos da solução por sua vez indicam quais são as características que ela deve possuir para atender aos requisitos do negócio e os requisitos das partes interessadas. Os requisitos da solução desenvolvidos ao longo do desempenho da área de conhecimento Análise de Requisitos e podem ser divididos em dois grupos, especialmente, mas não limitado a uma solução de software. O primeiro grupo se refere aos requisitos funcionais, que descrevem o funcionamento da solução, seu comportamento e as informações que ela irá gerenciar. O segundo grupo contém os requisitos não funcionais, conhecidos como requisitos de qualidade ou suplementares, como eficiência, velocidade, disponibilidade, aparência e as condições do ambiente sob as quais a solução irá operar.

Por fim, existem os requisitos de transição, um conjunto de requisitos temporários, importantes para a implantação da solução, mas necessários somente para que ela seja possível. Esses requisitos não podem ser desenvolvidos até que a solução atual e a nova solução sejam compreendidas e definidas. Geralmente esses requisitos envolvem tarefas como conversão de informações (dados de um sistema antigo para um sistema novo), treinamentos para que a nova solução possa ser operada e capacidades como redundâncias e trabalhos paralelos (processo novo e antigo sendo desempenhados em paralelo, por exemplo).

 1.4.Áreas de conhecimento

As áreas de conhecimento da Análise de Negócios agrupam tarefas e técnicas com um objetivo em comum, contudo, elas não indicam uma ordem de execução, como fases em um projeto. Por exemplo, é comum iniciar um esforço de Análise de Negócios pela tarefa “Definir a Necessidade do Negócio”, pertencente à área de conhecimento Análise Corporativa, ou “Avaliar o Desempenho da Solução”, da área de conhecimento Definição e Validação da Solução.

Dentro das iniciativas de Análise de Negócios, o analista costuma percorrer todas as áreas de conhecimento em uma sucessão rápida, de forma iterativa ou até simultânea. Isso ocorre porque as tarefas podem ser executadas em qualquer ordem uma vez que as entradas necessárias estejam disponíveis.

Apesar das áreas de conhecimento não representarem obrigatoriamente, como dito, fases de um projeto. É certamente possível e permissível partir das atividades de Análise Corporativa para as atividades de Análise de Requisitos e então para a Definição e Validação da Solução tratando cada uma como uma fase distinta de um projeto, contudo, essa seqüência não deve ser imposta como uma metodologia para a execução da Análise de Negócios.

 

1.4.1.Planejamento e Monitoramento da Análise de Negócios

As tarefas presentes nesta área de conhecimento governam a execução das demais tarefas da Análise de Negócios. Elas cobrem como são determinadas quais atividades serão necessárias para que o esforço de Análise de Negócios seja completo com sucesso. Isso envolve a identificação das partes interessadas, o processo utilizado para o gerenciamento dos requisitos, as técnicas a serem utilizadas e como o sucesso do esforço será avaliado. As principais tarefas desta área de conhecimento são:

• Identificação das partes interessadas;
• Definição dos papéis e responsabilidades das partes interessadas dentro do esforço de análise de negócios;
• Desenvolvimento de estimativas para as tarefas de análise de negócios;
• Planejamento da forma de comunicação entre o analista de negócios e as partes interessadas;
• Planejamento de como os requisitos serão abordados, traçados e priorizados;
• Determinação dos entregáveis que a análise de negócios irá produzir;
• Definição e determinação dos processos de análise de negócios;
• Determinação das métricas que serão utilizadas para monitorar o trabalho de análise de negócios;

 

1.4.2.Elicitação

E elicitação (em inglês, “Elicitation”) descreve o trabalho dos analistas de negócios no intuito de compreender as necessidades e preocupações das partes interessadas e os ambientes no qual elas trabalham ou operam.

A grande diferença entre o termo “elicitar” requisitos e o termo mais comum “levantar” é o foco na extração das necessidades verdadeiras, que costumam muitas vezes estar explícitas, não se satisfazendo com a simples expressões de desejos superficiais.

A elicitação dos requisitos não costuma ocorrer de forma isolada ou em compartimentos. Requisitos costumam aparecer de forma cíclica durante sessões tanto de levantamento quando de validação.

A elicitação costuma envolver uma combinação de técnicas para que a definição dos requisitos seja executada de forma completa. A definição de quais técnicas serão utilizadas depende de diferentes fatores, como o domínio do negócio, a cultura e o ambiente do negócio, as habilidades do analista e quais tipos de entregáveis de requisitos devem ser criados. As técnicas de elicitação geralmente aceitas são: brainstorming, análise documental, grupos focais, análise de interfaces, entrevistas, observação, prototipagem, workshops de requisitos e pesquisa/questionários.

As tarefas da elicitação envolvem a preparação, condução, documentação e confirmação dos resultados da elicitação.

 

1.4.3.Gerenciamento e Comunicação dos requisitos

Conflitos, incidentes e mudanças são inerentes ao processo de definição dos requisitos. O analista de negócios deve saber gerenciar essas situações para garantir que as partes interessadas e a equipe da iniciativa ou projeto permaneçam em acordo a respeito do escopo da solução. Esta área de conhecimento também abrange a definição de como os requisitos são comunicados às partes interessadas e como o conhecimento obtido pelo analista de negócios é mantido para utilização futura.

O objetivo do gerenciamento e comunicação dos requisitos é estender a todos a compreensão dos efeitos das mudanças trazidas pela solução e as ligações entre a solução e os objetivos e metas do negócio.

A comunicação é fator ao mesmo tempo crítico e difícil para o sucesso de qualquer iniciativa, uma vez que as partes interessadas representam pessoas de diversas origens e áreas profissionais.

As tarefas desta área de conhecimento são:

• Gerenciar o escopo e os requisitos da solução: manutenção do consenso entre as partes interessadas quanto ao escopo genérico da solução e os requisitos que serão implementados;
• Gerenciar a rastreabilidade dos requisitos: Criação e manutenção dos vínculos entre os requisitos do negócio, das partes interessadas, da solução, os componentes da solução e outros artefatos, garantindo o alinhamento.
• Manter requisitos para reuso: Gerenciamento do conhecimento sobre os requisitos para uso futuro.
• Preparar o pacote de requisitos: Estruturação de um conjunto de requisitos de forma apropriada para que sejam comunicados, entendidos pelas partes interessadas.
• Comunicar requisitos: Conversas, anotações, documentos, apresentações e discussões fazem parte desta questão fundamental para levar as partes interessadas a uma compreensão comum dos requisitos.

 

1.4.4.Análise corporativa

Freqüentemente a análise corporativa é o ponto de partida para uma iniciativa, já que suas atividades envolvem a identificação da necessidade do negócio (razão de ser fundamental da iniciativa em análise), problema ou oportunidade, define a natureza de uma solução que atenda a essa necessidade e trabalha para justificar o investimento necessário para a entrega dessa solução.

Os resultados deste trabalho provêm contextualização para a Análise de Requisitos e identificação da solução para uma data iniciativa ou planejamento de longo prazo, pois descreve as atividades de Análise de Negócios que são empregadas para:

• Compreender completamente os problemas e oportunidades do negócio através da análise da situação do negócio;
• Compreender a mudança necessária para atender às necessidades do negócio e atingir as metas estratégias através da avaliação das capacidades da organização;
• Desenvolvimento do plano de negócios e da solução proposta a partir da definição do escopo da solução;
• Definir e documentar os requisitos do negócio (incluindo a necessidade do negócio, capacidades requeridas, escopo da solução e plano de negócios).

As tarefas da Análise Corporativa são:

• Definir a necessidade do negócio: Identificar porque uma mudança nas capacidades ou sistemas organizacionais é necessária (a razão de ser da iniciativa). Trata-se da definição do problema para o qual o analista está tentando encontrar a solução. A definição da necessidade do negócio orienta quais soluções serão consideradas, quais partes interessadas serão consultadas e quais abordagens de solução serão aceitas;
• Avaliar lapsos de capacidade: Identificação de quais são as capacidades necessárias para a organização atender à necessidade do negócio. Essas capacidades (estrutura, pessoas, processos e tecnologia) podem já ser possuídas pela organização, o que faz a mudança tender a ser pequenas, ou não, o que tende a envolver iniciativas mais complexas;
• Determinar a abordagem da solução: A abordagem da solução deve ser selecionada com base na sua viabilidade para o atendimento da necessidade do negócio. Ela deve ser definida em um nível de detalhe suficiente para a definição do escopo da solução e conseqüente preparação do plano de negócios;
• Definir o escopo da solução: Definição de quais são as novas capacidades que a iniciativa (ou parte de uma iniciativa) deverá entregar;
• Definir o plano de negócios: Determinação de se o investimento necessário para a entrega da solução é justificado. Esta justificativa se baseia no valor a ser adicionado ao negócio como resultado da solução implantada em comparação com o custo de desenvolvimento desta solução;

 

1.4.5.Análise de requisitos

A Análise de Requisitos descreve a priorização e elaboração progressiva dos requisitos das partes interessadas e da solução para permitir que a equipe da iniciativa ou projeto implemente a solução que deverá atender à necessidade do negócio.

Esta área de conhecimento também envolve a elaboração de modelos do estado atual da organização utilizados para a validação do escopo da solução.

As tarefas da Análise de Requisitos são:

• Priorizar requisitos: A priorização garante que os esforços são aplicados primeiro sobre os requisitos mais críticos;
• Organizar requisitos: Criação de um conjunto de visões dos requisitos que sejam compreensíveis, completas e consistentes para as partes interessadas em suas diferentes perspectivas;
• Especificar e modelar requisitos: Utilizar um conjunto de declarações em texto, matrizes, diagramas e modelos formais para analisar os desejos expressados pelas partes interessadas e/ou o estado atual da organização;
• Definir pressupostos e restrições: Identificação de fatores além dos requisitos que afetam a viabilidade das soluções;
• Verificar requisitos: Garantia de que as especificações e modelos atendem ao padrão necessário de qualidade para que possam ser utilizados;
• Validar requisitos: Garantia de que todos os requisitos apóiam a entrega de valor para o negócio, que eles atendam às suas metas e objetivos e às necessidades das partes interessadas;

 

1.4.6.Definição e validação da solução

A Definição e Validação da Solução se destina a determinação de qual solução se encaixa melhor à necessidade do negócio, a identificação de lapsos de capacidades ou falhas em soluções e a determinação de contornos ou mudanças necessárias.

O analista de negócios deve também avaliar o quão bem uma solução entregue atende à necessidade original para qual foi desenvolvida, permitindo que a organização julgue o seu desempenho e eficácia. Isso envolve a avaliação e validação de componentes de soluções como processos de negócio, estruturas organizacionais, acordos de terceirização, aplicações de software entre outros. Por conhecer o ambiente do negócio, o analista de negócios pode avaliar os impactos de cada solução proposta sobre o ambiente.

Estas atividades possuem como objetivo principal a maximização do valor entregue para as partes interessadas.

As tarefas da Definição e Validação da Solução são:

• Avaliar solução proposta: Avaliação das soluções propostas para a determinação do quão bem elas atendem aos requisitos das partes interessadas e da solução;
• Alocar requisitos: Alocar os requisitos aos componentes da solução com o objetivo de maximizar o valor entregue ao negócio dadas as opções e alternativas disponíveis;
• Avaliar a prontidão organizacional: Avaliar se a organização está preparada para o uso efetivo de uma nova solução a partir da compreensão dos seus efeitos;
• Definir requisitos de transição: Definição das capacidades necessárias para a transição entre a solução existente e a nova solução;
• Validar a solução: Validar que a solução atende à necessidade do negócio e respostas apropriadas para eventuais defeitos identificados;
• Avaliar desempenho da solução: Avaliação de soluções em funcionamento para a compreensão do valor que elas entregam em busca de oportunidades de melhoria;

 

1.4.7.Competências de apoio

Comportamentos, conhecimentos e outras características que apóiam o desempenho efetivo da Análise de Negócios são abordados nesta área de conhecimento.

As competências de apoio são:

• Pensamento analítico e solução de problemas: Pensamento criativo, tomada de decisão, aprendizado, resolução de problemas e pensamento sistêmico;
• Características de comportamento: Ética, organização pessoal e confiabilidade;
• Conhecimento de negócios: Princípios e práticas de negócios, conhecimento da indústria, conhecimento da organização, conhecimento da solução;
• Habilidades de comunicação: Comunicações verbais, ensino, comunicações escritas;
• Habilidades de interação: Facilitação e negociação, liderança e influência, trabalho em equipe;
• Aplicações de software: Aplicações de propósito geral, aplicações especializadas.

  

 Fonte: Resumo BABOK 2.0 (www.kerber.com.br)

Os sete erros das finanças

De cada dez e-mails que chegam para a seção Divã do Empreendedor, nove são de empresários que estão passando por problemas financeiros e não sabem como resolver. Saldo no vermelho, dívidas com bancos, impostos atrasados, falta de capital de giro, dificuldade em conseguir dinheiro para expandir a empresa: são muitas as dúvidas que assaltam os empreendedores afogados em números. Analisando as cartas, fica fácil perceber que muitos deles chegaram nesse ponto por causa de erros comuns, que poderiam ser evitados com algumas noções básicas de gestão e um pouco de bom senso.

Confira aqui os sete erros mais frequentes cometidos na área de finanças, segundo Brian Hamilton, fundador da consultoria Sageworks e colunista da Inc.

1. Contar vitória antes do tempo. Existem empreendedores que, depois de assinar alguns contratos, agem como se o dinheiro já estivesse na conta. Otimistas, contratam funcionários, compram equipamento, investem em melhorias. Basta um cliente voltar atrás para que as finanças virem um desastre.
2. Pedir dinheiro emprestado sem necessidade. Sempre que possível, utilize seus próprios recursos para crescer. Saber quais linhas de crédito estão à sua disposição é sempre uma boa pedida. Usar esse crédito sem necessidade é uma temeridade. Empréstimos são um motivo a mais de preocupação – especialmente quando a empresa não tem condições de pagá-los.
3. Atrasar o pagamento de impostos. Muitos empresários cometem esse erro, acreditando que será mais fácil saldar a dívida mais tarde. Acredite:  juros e multas fazem com que o pagamento se torne ainda mais complicado.
4. Colocar preços baixos nas mercadorias. Baixar os preços para lucrar mais é uma estratégia que só funciona para as grandes redes varejistas. Se você não se enquadra nesse padrão, melhor vender menos produtos a preços mais altos. Dessa maneira, a empresa têm a sua margem de lucro protegida, além de valorizar a marca.
5. Permitir compras à prazo. Quando um empresário concede crédito ao cliente, ele está criando um risco desnecessário. Se for possível, venda apenas à vista. Nem todos especialistas concordam nesse ponto, mas a verdade é que muitos empreendedores fracassam porque não conseguem manter um fluxo de caixa saudável – em boa parte, por causa das vendas à prazo.

6. Colocar todos os ovos em uma cesta só. Nunca dependa de uma única fonte de receita. Ter um cliente só, que paga todas as contas, parece cômodo – até que o cliente desaparece, levando junto todo o lucro da empresa. Diversificar para sobreviver: este deveria ser o tema de todas as startups que sonham em crescer.

7. Contratar pessoas sem critério. Nos primeiros anos, reduzir custos com pessoal é fundamental. Verifique se seus funcionários colaboram para as vendas, criam produtos ou prestam algum tipo de serviço. Se algum deles não faz nada disso, há algo errado com a empresa.

Fonte : http://www.papodeempreendedor.com.br/oportunidades/os-sete-erros-das-financas/