Hi
I'd like to discuss business models in Export Compliance.
I have come across three models.
Model 1: Physical exports: This model involves an order life cycle that is typically between 1 day to up to a few months. The shipment of product needs to be accompanied with documents such as the commercial invoice that need to have export licensing data on it. If the customers are repeat customers it would make sense to retain the latest restricted party list (RPL) screening results and also history. Since the order life cycle is a few days there is some breathing room for manual intervention to resolve RPL and export licensing issues.
Model 2: Online downloads: The second model is for products that don't need to be physically shipped. Example, online downloads. This model involves an order life cycle which ranges from a few seconds to a few minutes. Since the product doesn't need to be shipped there generally isn't a need for shipping documents. The customers aren't generally repeat customers and therefore their RPL results may not need to be reused and a history for the customer may not need to be retained. Since the order life cycle is a few minutes there is very little time for manual intervention to resolve RPL and export licensing issues. This model may have higher volumes that the first model.
Model 3: Site access: Export compliance screening may be required when customers, vendors and other persons access a company's facility. The life cycle of the transaction is a matter of seconds as the person is waiting to enter the building/facility. The person may not be a repeat visitor so the RPL screening results may not need to be retained. The history may also not need to be retained. Since the life cycle of the transaction is very short there may be little room for manual intervention to resolve issues. The volume of transactions in this model will vary based on the number of visitors.
Please add a comment if you are aware of another model.
Now moving to the applications that support these models. Let's say your company uses more than one model and your volumes/projected volumes are large.It makes absolutely good sense to have two applications/instances of an application support the two models. The only exception being the needs for model Model 2 and Model 3 may potentially be combined into one. I think having one application that satisfies the needs for Model 1 and Model 2 isn't the best course of action.
Let me know your thoughts/comments.
Cheers
Subscribe to:
Post Comments (Atom)
Posts
4 comments:
Hi Giri,
Thanks for taking time to maintain a blog on this subject.
First, I think there is another model, although it may simply be a hybrid of the first one above: "Re-exports" often require multiple regulations to be applied because different rules apply from the original country of export and the country of 're-export'. For example, a shipment from Japan, to S.Korea to the US will need to comply with both Japanese and Korean export regs.
Also, I must respectfully disagree with the assertion that one application should not be used to satisfy all these models. As a consultant who implements such systems, I can cite two reasons for centralization of compliance policy and system management:
1. Reduction of master data management (multiple systems means multiple sets of RPL lists, HTS codes, ECCN values, and so on). This can promote dis-synchronization and create compliance gaps.
2. Minimizing staff for compliance oversight. Multiple systems can mean inconsistent application of policies. One system screens and releases against the same RPL entity that the other system places a hold on. Not good at audit time.
Hey, keep up the good work and I wish you the best. I hope this blog and its followers continue to grow !
Giridi / Greg,
I would agree with Greg, there is no tangible reason why all compliance screening should not sit in one platform, as different transaction types with different resolution queues.
A comprehensive GTM product should be able to handle these feeds from numerous ERP's, web access, management of screening and resolution services in different queues and full reporting and analytics.
In a complex hi tech environment you will see the physical export of the product from the USA (with USA license requirements), configuration and re-export of this product from the EU (with EU and USA license requirements) to end user and then the end user using some web form to activate the software in the system or download the license – all of this will use the same product and end user data so critical it is in one place.
To Greg’s point this will centralise data, improve audit trails and provide economical efficiencies when looking at software costs and licensing.
This is obviously utopia; I am still working with some prospects and clients that cannot envisage their global (USA / EU / APAC) transactions through one system!
The GTM space is exciting and maturing every day, a great place to be!
Craig Hooper
Another export model could be technical data export or 'deemed exports' as the trade compliance folks at BIS would tell you. This is to control the transmission of sensitive and restricted data, that would otherwise require an export license, by electronic (email) or verbal (speech) means. The export could take place in the U.S. to foreign nationals or on overseas visits by U.S. persons.
Under ITAR a conversation revealing technical data would require a permanent export license (DSP-5) before the U.S. person can speak in these terms to a potential client (non-U.S. person).
You will find the definition of the terms technical data, U.S. person and foreign national in ITAR.
Hi Greg, Ashok and Anonymous
Thanks for your comments. My contention is that when a comapny has huge transaction volumes for export compliance screening it makes sense to have more than one platform. When I say huge I mean millions of transactions a year. If a company has a huge corporate/enterprise business and a small consumer business they can attempt to use one platform. To be able to do this will need to come up with hardware and software that fits both worlds. It's kind of like finding a cross between a classic car and a new sports car. To be able to achieve this the hardware will have to scale to the model that has more performance needs. Saying it differently this hybrid will need the sports car's engine. Also, the software should be configurable/modifiable enough to enable the two business models to coexist. Easy on paper but much harder to implement.
As far as master data is concerned, the IT world is migrating towards product data hubs. I think this would be a logical place to store classification data associated with a product/sku. The product data hub would be responsible for real time communication of changes in classification to all the platforms. I will try and put out a slide presentation on this model in one of my future posts.
As far as RPL master data is concerned, yes this will have to be maintained in each platform. Some software support automated updates with no human touch and in this case it wouldn't be a biggie. In the case where human touch is required it would be small price to pay compared to creating a hybrid between a sports car and a classic.
The reexport sounds very similar to the enterprise/corporate type of business and the deemed export similar to the consumer business so we could put them on those platforms.
If you would like to coonect please send me an invite on linkedin.
Let me know your thoughts.
Cheers
Giri
Post a Comment