Desconto de 50% em talão é, no melhor caso, um desconto de 33,3%

A propósito do desconto em talão, o que na REALIDADE significa? Qual o desconto REAL que conseguimos?
Então, tendo em conta dois pressupostos:

1. O consumidor faz duas compras;

2. O desconto é uma percentagem da primeira compra mas só é rebatido (descontado) na segunda compra (e esta já não tem desconto).

O desconto máximo que o consumidor consegue consiste em efectuar uma segunda compra exactamente igual ao valor do desconto obtido na primeira compra.

Então vamos analisar o exemplo que o professor Rogério indica:
- Valor da 1ª compra: 100
- Desconto em talão (para rebater na compra seguinte): 50%, ou seja, 50 euros
- Valor da 2ª compra: 50 euros (nesta compra, o consumidor paga 0 euros).

Em síntese:
- Valor total das compras: 150 euros
- Valor total pago: 100 euros
- Desconto global obtido (relativo às duas compras): 50 euros que, em percentagem corresponde a 50/150, ou seja, 33,33%.

Este é o desconto máximo que o consumidor consegue, efetuando uma segunda compra de valor exatamente igual ao desconto que obteve na primeira. Se o valor da segunda compra for superior ao desconto obtido na primeira, esta percentagem (do desconto global obtido relativo às duas compras) é menor - e será tanto menor quanto maior for o valor da segunda compra). Estes 33,33% são, pois, o desconto máximo que se consegue no cenário indicado.

Ora, isto é exatamente 1 - 1/(1+taxa de desconto), como pode ver se fizer esta conta: 1 - 1/(1+0,50) = 0,3333 (33,33%). Na verdade, resulta no mesmo fazer 1 - 1/(1+taxa de desconto) ou simplesmente taxa de desconto/(1+taxa de desconto). No nosso exemplo, pode ver que 0,50/(1+0,50) resulta logo em 0,3333. Pode experimentar com outros valores e verá que isto é sempre verdade (desde que assumidos os tais dois pressupostos de que falei no início).

Outro exemplo:
- Valor da 1ª compra: 154
- Desconto em talão (para rebater na compra seguinte): 30%, ou seja, 46,20 euros
- Valor da 2ª compra: 46,20 euros (nesta compra, o consumidor paga 0 euros).
Em síntese:
- Valor total das compras: 200,20 euros (154 + 46,20)
- Valor total pago: 154 euros
- Desconto global obtido (relativo às duas compras): 46,20 euros que, em percentagem corresponde a 46,20/200,20, 23,077%. Também pode chegar a este valor de duas maneiras:
- Fazendo 1 - 1/(1+taxa de desconto). Fica 1 - 1/(1+0,30) = 0,23077 ou
- Fazendo taxa de desconto/(1+taxa de desconto): Fica 0,30/(1+0,30) = 0,23077
Se a segunda compra for de valor superior ao desconto obtido na primeira a percentagem de desconto global (relativa às duas compras) diminui.

Os descontos em talão não são tão lineares como parecem? Uma vez que normalmente os preços até estão mais altos do que o normal, e tendo em conta o facto de depois ainda irmos consumir outros igualmente centimos mais caros... pode não compensar!

Podem sempre consultar a Calculadora de Descontos em Talão, que o Pedro Pais disponibiliza no seu blog.

Créditos:
via Miguel Ângelo Rodrigues
Professor Rogério Matias calculofinanceiro.com

Universitários formados para exportação

Fonte: Jornal Sol

ATSI 7/7 - Conclusões

A metodologia seguida inicia-se com a definição da visão, missão e o ambiente de negócio em que a organização se enquadra. Delinearam-se os elementos fulcrais do negócio com recurso aos modelos das forças competitivas e da cadeia de valor.

Para fazer o levantamento dos processos de negócio, devem ser identificados os vários actores na organização para garantir uma visão completa. O resultado deverá ser uma listagem de processos coerentes com a perspectiva de cada actor e claramente complementares entre si, mas que no seu conjunto são difíceis de integrar numa só visão. Para resolver este problema, os processos devem ser reorganizados segundo o objectivo.

O levantamento das entidades informacionais deve seguir uma metodologia bottom-up. Os itens de informação necessários à execução dos processos devem ser identificados e agregados progressivamente, para formar entidades informacionais compostas por vários itens relacionados.

A identificação das aplicações deve seguir igualmente uma metodologia bottom-up. As aplicações candidatas devem ser propostas indivualmente e com nomes descritivos.

O impacto mais evidente na organização é o colmatar do fosso existente entre a visão de negócio e os sistemas informáticos. Tipicamente, quer a engenharia dos processos de negócio, quer a engenharia do software recorrem a muito detalhe, o que torna impossível a conversão de uma para outra linguagem de representação. A aproximação da Arquitectura de Sistemas de Informação desvaloriza o detalhe em ambos os lados, esbatendo a sua fronteira e criando a visão do conjunto focada no objectivo.

"One of the manifestations of the information processing profession’s youth is its tendency to dwell on detail. There is the notion that if we can get the details right, the end result will somehow take care of itself and we will achieve success. It’s like saying that if we know how to lay concrete, how to drill, and how to install nuts and bolts, we don’t have to worry about the shape or use of the bridge we are building. Such and attitude would drive a more mature civil engineer crazy."
- W.H. Inmon in “Building the Data Warehouse”


As metodologias abordadas para auxiliar a criação da arquitectura de aplicações envolvem os trabalhos de Spewak, Zachman e Inmon nesta área.

Uma das principais dificuldades na realização do levantamento de processos é conseguir uma visão por processos numa estrutura organizacional com divisão funcional (departamentos).

A metodologia de Spewak evidencia uma preocupação com a “forma de trabalho” para a obtenção da Arquitectura da Empresa, de onde se destaca o valor 80/20 como nível de detalhe necessário e suficiente. Além desta regra, conclui-se que ao identificar processos e identidades com algum detalhe é útil responder à pergunta “em que medida é que esse novo elemento identificará a existência de uma nova aplicação ou caracteriza melhor as aplicações existentes?”. Deste modo, pode-se averiguar da verdadeira importância dos processos e entidades levantadas.

Por outro lado, os documentos padrão apresentados por Spewak têm um nível muito elevado de detalhe que parece desalinhado com a regra dos 80/20.

A framework de Zachman, tem o seu principal valor na sua capacidade de identificar tudo o que é importante e decisivo na concepção de uma Arquitectura de Sistemas de Informação. A independência das ferramentas para identificar os elementos de cada célula da matriz (diagramas Entity Relationship, etc.), garantem a flexibilidade na sua aplicação. No entanto, tornam a framework difícil de ser utilizada como uma metodologia de construção da Arquitectura de Sistemas de Informação.

O trabalho de Inmon, é especialmente relevante na caracterização de dados e na cisão entre aplicações com dados operacionais e históricos. O uso das regras de Inmon, permitem caracterizar um dos factores tecnológicos mais importantes da aplicação: a natureza do seu repositório. Este repositório pode ter um de três tipos: repositório partilhado, repositório isolado ou repositório histórico (data warehouse).

ATSI 6/7 - Arquitectura Tecnológica

A arquitectura tecnológica define os tipos de tecnologia para suportar as aplicações que gerem e acedem à informação da organização. A definição destes ambientes pretende encarar a tecnologia de forma independente dos componentes funcionais e dos dados.

Os princípios tecnológicos propostos são:

Sistemas

• preferir sistemas abertos que sejam portáveis, escaláveis e que garantam a compatibilidade na interacção com outros sistemas;
  
• garantir o suporte ao multi-canal (atendimento directo, telefone, web, dispositivos móveis);
  
• definir, aplicar e auditar políticas de segurança respeitantes a todas as vertentes dos sistemas de informação: dados, software e hardware;
  

Comunicação

• utilizar protocolos de comunicação que sejam normas internacionais;
  
• facilitar o acesso aos sistemas promovendo a mobilidade e garantindo o débito adequado na comunicação;
  

Software

• preferir linguagens e ferramentas de programação abertas;
  
• utilizar metodologias estruturadas para o desenvolvimento de sistemas;
  

Dados

• capturar os dados relevantes apenas uma vez e o mais perto possível da fonte;
  
• minimizar a utilização de transacções distribuídas, preferindo manter a informação o mais perto possível do local onde é mais frequentemente utilizada;
  
• definir uma política de salvaguarda de dados e de recuperação de desastres adequada à importância de cada aplicação nos processos de negócio.
  
• preferir a utilização de bases de dados relacionais, utilizando SQL normalizado para aceder à informação;
  
• implementar o acesso a bases de dados numa camada própria;
  
• classificar todas as aplicações de acordo com o seu tipo principal de repositório: isolado, partilhado e histórico; e implementá-las no ambiente respectivo;
  

Interfaces

• definir, aplicar e auditar regras base comuns para as interfaces utilizador das aplicações, que facilitem a sua posterior integração. As principais características das interfaces deverão ser a simplicidade e a usabilidade;
  
• as aplicações deverão ter ou permitir a implementação de interfaces utilizador baseadas em tecnologias Web (HTML, etc.);
  
• as aplicações deverão ter ou permitir a implementação de interfaces programáticas baseadas em tecnologias de Web Services (XML, SOAP, etc.);
  

Sugerem-se os seguintes tipos de repositórios de dados para suportar as aplicações:

• repositório integrado - para as aplicações que partilham a maior parte dos dados umas com as outras;
  
• repositório isolado - para as aplicações cuja maior parte dos seus dados são de consumo próprio e apenas alguns são partilhados com outras aplicações;
  
• common data interface - repositório comum de dados onde são publicados os dados dos repositórios isolados que são partilhados (com o objectivo de garantir a independência computacional);
  
• repositório histórico (data warehouse) - para as aplicações que acedem a dados históricos apenas em modo de consulta.
  

O repositório integrado, os repositórios isolados e a common data interface deverão conter apenas dados operacionais. Toda a informação histórica deverá ser colocada no data warehouse. A principal razão para a separação física dos dados históricos dos dados operacionais é o tipo de acesso que se pretende e o tempo de resposta. No caso dos sistemas operacionais, são característicos os acessos frequentes de leitura e escrita a pequenos volumes de dados com tempos de resposta curtos. No caso dos sistemas de exploração de dados, são característicos os acessos a grande volume de dados, dispersos no tempo, de leitura e com tempos de resposta longos.

Em resumo:
Aplicações com repositório integrado - fazem a maior parte do processamento de dados resultantes da actividade.

Aplicações com repositório isolado, com publicação na common data interface - fazem um processamento de dados mais restritos, dispondo de repositórios de dados individualizados.

Aplicações com repositório de dados históricos - acedem ao repositório de dados históricos e executam pesquisas heterogéneas aos dados armazenados. Em regra geral são pesquisas de âmbito estratégico para apoio aos decisores.

A descrição da tecnologia de cada aplicação inclui os seguintes aspectos:

• Repositório – tipo de repositório da aplicação: integrado, isolado ou histórico;
  
• Tecnologia de armazenamento de dados – tipo de armazenamento de dados da aplicação: base de dados relacional ou ficheiros;
  
• Decomposição em camadas – arquitectura de camadas da aplicação: uma camada (monolítica), duas camadas (cliente - servidor) ou três camadas (apresentação - negócio - dados);
  
• Middleware – tipos de middleware utilizados pela aplicação - plataforma;
  
• Hardware – requisitos especiais da aplicação relativamente ao sistema computacional que a vai executar;
  
• Ambientes – ambientes necessários para suportar a aplicação durante o seu ciclo de vida (desenvolvimento, testes, pré-produção, produção);
  
• Interfaces – interfaces a desenvolver para a aplicação;
  
• Backup and disaster recovery – política de salvaguarda periódica de dados da aplicação e política de recuperação de desastres.
  

ATSI 5/7 - Arquitectura de aplicações

Um dos principais propósitos da definição da Arquitectura de Sistemas de Informação é resolver os problemas de incoerência e redundância nos dados e aplicações da organização.

A definição da Arquitectura de Processos de Negócio e a Arquitectura de Informação são o primeiro passo nesta definição, para garantir o alinhamento dos processos de negócio com as entidades informacionais.

O segundo passo consiste em utilizar as arquitecturas definidas e alinhadas entre si anteriormente, para conceber a Arquitectura de Sistemas de Informação. Esta concepção deve ter duas preocupações: o alinhamento dos sistemas de informação com os processos de negócio e, simultaneamente, o alinhamento dos sistemas de informação com as entidades informacionais. Assim sendo, assegura-se que os Sistemas de Informação suportam as acções desempenhadas pelos actores nos processos de negócio e que gerem exactamente a informação necessária (nem a mais, nem a menos).

Depois de definidas as aplicações, deve-se assegurar a conformidade futura a nível do alinhamento tecnológico, propondo uma Arquitectura Tecnológica e um Plano de Implementação

A arquitectura de aplicações define e descreve o conjunto de sistemas ideal para uma organização, identificando as inter-dependências existentes. O seu objectivo é identificar os componentes funcionais da arquitectura e assegurar que estes estão alinhados com o negócio e com a estratégia, promovendo a gestão eficaz da informação. Esta definição é independente da tecnologia.

O ponto de partida para esta definição é uma Matriz de CRUD que resume as Arquitecturas de Processos de Negócio e de Informação.

A metodologia para definir a arquitectura de aplicações é a seguinte:

• Análise da matriz inicial obtida pelo cruzamento dos processos de negócio com as entidades informacionais, identificando as principais concentrações de criação (C) e actualização (U) de entidades;
  
• Identificação de aplicações candidatas, com definição do nome e objectivo:
  
  • partindo directamente da matriz:
    
    • aplicações orientadas às entidades (colunas da matriz);
      
    • aplicações orientadas aos processos (linhas da matriz);
      
  • partindo do conhecimento do problema adquirido durante a definição dos processos de negócio e entidades informacionais;
    
• Criação da lista de aplicações eleitas, através da combinação das várias listas de candidatas com eliminação de aplicações repetidas e redundantes;
  
• Análise iterativa da matriz para identificação dos aglomerados correspondentes às aplicações. Agrupamento de entidades e processos por afinidade, através de permutas de linhas e colunas. Ajuste das aplicações eleitas;
  
• Definição da lista final de aplicações a propor, com descrição completa dos objectivos e das macro funcionalidades.
  

A descrição de cada aplicação deve incluir os seguintes aspectos;

• Objectivo – descrição dos problemas que a aplicação pretende resolver;
  
• Tipo de Sistema – classificação do tipo de sistema de acordo com o nível da organização em que é utilizado (TPS/KWS/MIS/DSS/ESS - ver abaixo);
  
• Macro Funcionalidades – descrição das principais funcionalidades da aplicação, agrupadas em módulos quando necessário;
  
• Interfaces de Integração – para permitir a integração com outras aplicações. Pode ser uma interface de programação aplicacional (API) ou uma interface de acesso aos dados;
  
• Processos Suportados – lista de processos de negócio suportados pela aplicação;
  
• Entidades Geridas – lista de entidades informacionais que são criadas, lidas, actualizadas ou eliminadas pela aplicação (CRUD);
  
• Entidades Consultadas – lista de entidades informacionais que são apenas lidas pela aplicação (R).
  

Os sistemas de informação servem as funções das organizações a diferentes níveis [ver Laudon e Laudon]. As áreas funcionais são tipicamente Vendas e Marketing, Produção, Finanças, Contabilidade e Recursos Humanos; os níveis são: Estratégico, Gestão, Conhecimento e Operacional. Os sistemas de informação são classificados em diferentes tipos, dependendo do nível da organização que assistem:

• Sistemas de Processamento de Transacções (TPS – Transaction Processing Systems) – sistemas do nível operacional, que registam as transacções diárias necessárias aos processos de negócio;
  
• Sistemas de Trabalho de Conhecimento (KWS – Knowledge Work Systems) –sistemas de apoio a trabalhadores especializados em áreas de conhecimento, na criação e integração de novo conhecimento na organização;
  
• Sistemas de Informação de Gestão (MIS – Management Information Systems) –sistemas ao nível de gestão utilizados para funções de planeamento, controlo e decisão baseados em relatórios rotineiros de resumo ou excepção;
  
• Sistemas de Apoio à Decisão (DSS – Decision Support Systems) – sistemas ao nível de gestão que combinam dados e modelos analíticos ou ferramentas de análise de dados para apoiar as decisões não rotineiras;
  
• Sistemas de Apoio Executivo (ESS – Executive Support Systems) – sistemas ao nível estratégico concebidos para auxiliar nas decisões não rotineiras, utilizando técnicas avançadas de comunicação e representação gráfica.
  

ATSI 4/7 - Matriz de CRUD

A matriz de CRUD apresenta um cruzamento entre processos de negócio e entidades informacionais, ou seja, permite visualizar que dados são usados (e de que forma) em cada processo de negócio.

A imagem seguinte apresenta um exemplo de uma matriz de CRUD:

Pesquisar mais exemplos

ATSI 3/7 - Arquitectura de Informação

A arquitectura de informação é a descrição das entidades informacionais necessárias para a realização dos processos de negócio da organização. Esta arquitectura identifica e define a informação fundamental para o negócio de forma independente das aplicações que irão existir, formando a base que vai permitir a gestão correcta da informação.

Sugere-se a seguinte metodologia para a identificação e definição das entidades informacionais:

• Listagem conjunta de entradas e saídas de um grupo de processos;
  
• Agregação dos itens de informação por afinidade;
  
• Definição de entidades candidatas, com indicação do respectivo dono;
  
• Agregação ou separação de entidades candidatas;
  
• Ajuste do nível de detalhe das entidades e seus atributos, tendo em conta o objectivo da modelação;
  
• Definição das entidades informacionais;
  
• Verificação da coerência global das entidades e da relação entre as entidades e os processos de negócio.
  

As entidades informacionais são apresentadas da seguinte forma:

• Código Identificador – EI x, onde x é um número;
  
• Nome – descreve a designação da entidade;
  
• Dono da Entidade – quem cria a entidade;
  
• Gestor da Entidade – quem gere a maior parte do conteúdo da entidade;
  
• Descrição – genérica da entidade;
  
• Identificador – atributos que permitem identificar uma instância da entidade informacional;
  
• Atributos Contidos – descrição dos atributos de informação contidos na entidade. Cada atributo é sumariamente descrito.
  

Cada atributo das entidades tem, por omissão, grau de derivação: primitivo; dimensão grau de privacidade: pública; dimensão temporal: tempo presente.