Otm 2013 c13_e-23b-hatcher-neil-otm-gtm-data-maintenance
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


Otm 2013 c13_e-23b-hatcher-neil-otm-gtm-data-maintenance






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Otm 2013 c13_e-23b-hatcher-neil-otm-gtm-data-maintenance Presentation Transcript

  • 1. Achieving Maturity inOTM ImplementationProcesses – Part 1Best practice definitions for Data Managementand User Access Management
  • 2. History §   Oct  2005  (just  before  Oracle  acquired  GLog)  –  under  20  OTM   implementors  within  Europe   •   Success  in  Projects  achieved  through  individual  endeavours   •   Regular  issues  with  deployment  to  producHon  –  typos  in   agent  code,  missing  master  data  etc   •   Regular  issues  with  user  provisioning,  eg  Hckets  raised  by   business  as  user  in  Poland  is  seeing  currency  in  USD  etc  
  • 3. History continued § 2006  thru  2009  (Steady  growth  of  OTM  install  base  within   Europe)   •   “Home  grown”  tools  emerge  built  by  individual   implementors  to  solve  their  needs  at  a  parHcular  point  in   Hme  (excel  funcHons,  excel  with  vba,  access  db,  pl/sql,  vb,   java  applet)   •   Lack  of  consistency  in  approach  between  implementaHons   •   Clients  encounter  performance  problems  leading  to   learnings  about  do’s  and  don’ts  -­‐>  fed  back  through   development  to  become  the  “Performance  tuning  guide   • Projects  delivered  successfully  but:   §   risk  of  “home  grown”  soluHons  become  unsupportable   when  the  originaHng  implementor  leaves  the  project   §   resources  have  to  learn  new  processes  when  moving   from  one  project  to  another  
  • 4. History continued § 2010  onward  (Rapid  growth  of  OTM  install  base  within  Europe)   •   Conscious  effort  to  define  best  pracHces   •   Aim  to  have  consistent  approach  across  all  of  our  new   projects   •   New  breed  of  clients  purchasing  OTM  who  previously   developed  so^ware  in  house.  -­‐>  Strict  code  management  and   deployment  processes  in  place  which  have  to  be  met.   • We  start  to  migrate  “home  grown”  tools  to  common   enterprise  grade  producHsed  plaaorm   § Result  is  that  we  have  now  got  defined  best  pracHces  and  are  in   the  process  of  rolling  those  out  across  Mavenwire.  
  • 5. Data Loader Rate Maintenance Challenges How to get the rates from Excel to OTM
  • 6. Data Management Best Practices §   Remove  the  IT  middleman  from  the  day  to  day  process  and   allow  the  business  end  user  who  is  responsible  for  the  data  to   also  load  the  data   • To  do  this  the  process  must  not  require  the  person  transforming  the  raw   data  and  uploading  it  to  OTM  to  have  any  knowledge  of  scripHng/macro/ coding  languages   • The  process  should  be  efficient  to  use  (minimal  number  of  mouse  clicks   etc)   § Use  robust  repeatable  process   • TransformaHon  of  the  raw  data  must  produce  idenHcal  results  every  Hme   •   Define  consistent  naming  convenHons   •   Validate  the  data  is  correct   •   IdenHfy  data  formaeng  issues   •   Avoid  recurrent  errors   • Verify  that  foreign  keys  exist  in  OTM  already  
  • 7. Data Management Best Practices § The  transformaHon  must  be  able  to  evolve  over  Hme   • Adapt  to  new  opportuniHes  (e.g.  modes,  services)     • Simple  way  for  IT  to  handle  change  requests  to  the   transformaHon  (e.g.  new  modes,  services)   • Naming  convenHon  change  should  cascade  to  child  objects   with  minimal  effort   §     Data  should  be  Consistent  across  environments   • e.g.  new  locaHons  loaded  to  Prod  should  also  be  loaded   efficiently  to  test  environments   §   The  end  user  should  be  able  to  download  the  exisHng  data,   make  modificaHons  and  reload  the  new  data   §   When  new  versions  of  rates  are  loaded,  the  old  version  should   be  automaHcally  expired  (this  should  not  rely  on  the  naming   convenHon)  
  • 8. User Access Mgmt Best Practices §   Define  one  consistent  model  for  user  access  configuraHon   § “Level”  and  VPD  profile  are  for  the  funcHonal  role   § VPD  context  is  for  the  geographical  element   § User  role  brings  together  the  funcHonal  role  and  the   geographical  element.   § User  provisioning  should  require  creaHon  of  a  gl_user  record   and  assignment  of  one  or  more  user  roles  and  absolutely   nothing  else.   §   AcHon  checks,  acHon  morgs,  menus,  status  type  filters,  default   finder  sets  are  funcHonal  role  related  so  should  be  agached  to   the  “level”   § Timezones,  currency,  business  monitor  and  therefore   preference,  along  with  saved  query  filters  are  geographical   based  and  should  be  agached  to  the  user  role.  
  • 9. Data Loader Rates maintenance Options BUSINESS  NEEDS   §     Through  the  UI?   New Contracts •   MulHple  objects/tabs   Contract •   Time  consuming   Expiry     §   IntegraHon?   Rate Updates •   Disparate  source  data     Scheduled •   No  Rate  interface   Adjustments (e.g. Fuel)   §   CSV  file  upload?   Preferred Carriers •   How  do  you  generate   the  csvs  for  many  tables   •   How  is  it  supported?   •   How  is  it  managed?   •   Where’s  the  audit  trail?  
  • 10. User Access Mgmt OptionsBUSINESS  NEEDS   §     Through  the  UI?   •   MulHple  objects/tabs   Role out •   Time  consuming  functionality to new •   Edit  User  Access  screen   geographical only  available  to   region “ADMIN”  Level   §   IntegraHon?   Add newaction check to •   No  interface   all users §   CSV  file  upload?   •   How  do  you  generate   the  csvs  for  many  tables   •   How  is  it  supported?   •   How  is  it  managed?   •   Where’s  the  audit  trail?  
  • 11. How are we internallyimplementing these BestPractices?
  • 12. Data Loader User AccessFacilitate the businessto load their own data Managerefficiently and robustly Facilitate rapid and robust user provisioningData Archiver& Cleaner ConfigurationMeet legal requirements forlong term storage of critical Managerdata while keeping your Robust deploymentprimary database running processesefficiently with minimal livedata Deliver Support tool for issue, request, feature and bug tracking
  • 13. Data Loader Data Loader §  Supports multiple environments with different OTM version §  User Friendly error handling §  Miscellaneous validation & conversion rules §  Data can be pushed directly into OTM or loaded using csvutil zip file through the OTM UI §  Very quick and robust process §  UI for IT personnel to easily manage and create new templates §  Extract Data from OTM back into Excel §  User  Security  &  Help  
  • 14. Data Loader Data Loader Templates Template for OTM csv for CE TL RATES CE TL RATES Template for OTM csv for NE RAIL RATES NE RAIL RATES Template for OTM csv for LOCATIONS LOCATIONS §  Validation Rules §  Mapping Rules §  Versioning Rules
  • 15. User Access Manager User Access Manager §  Supports multiple environments with different OTM version §  Locking Mechanisms to force serialisation of tasks if they collide. §  Saved queries built from templates plus parameters §  Uniform naming conventions enforced across all geographies §  Time to create action checks greatly reduced §  Load to OTM directly or using csvutil zip file  
  • 16. Data Loader Data Loader Process §   Start  with  an  empty  (or  pre-­‐populated)  spreadsheet   •   Send  to  Pricing  Team   •   Send  to  Carrier   §   Upload  spreadsheet   •   Validate   2 •   Error  Handling   §   Load  into  OTM   •   csv  zipfile   3 •   or  direct  db   1
  • 17. Data Loader Demonstration
  • 18. Data Loader Other Uses §  Load test data into OTM for OTM testing before integration feeds have been built §  Load performance test data - eg > 100000 orders with related shipments etc ready for inbound and outbound message testing §  Extract business objects from production and load them into a test environment for issue replication §  Prototyping §  Load test data onto integration stub tables
  • 19. Questions ? Questions and Answer Email: LearnMore@MavenWire.com