Archive for March, 2009

Sonic Assault Studio

Posted: March 16, 2009 in music
Tags: , ,

Okay so it sounds more impressive than it really is, but still I’m pretty psyched about it.   I’d been playing lots of Guitar Hero and Rock Band with (and without) the kids and I just kept thinking about getting out my real guitar and playing.  Some of the songs are actually easier to play for real than they are in the game.  So around July of last year, I went digging for my guitar in the back of the closet, and started trying to remember the scales and the other stuff I used to be able to play.  It was a blast and even though the fingers complained for the first couple of weeks I kept on playing, trying to get back into some kind of playing shape.  I just played on the guitar without any amplification.

Then around August I decided it was time to hear what I was playing and maybe be able to record.  I didn’t want to shell out for a real amp, which would just annoy the rest of the family.  So I spent 90 bucks to get the Line 6 Toneport UX1 and the “studio” was born.    The amp modeling in the Toneport is great and since I was in the family room I could totally crank up the volume and rock out without driving anyone crazy.  I tried both the Riffworks demo and the free Kristal audio engine as my DAW.  I used both, but not a whole lot since there wasn’t much to record as I was trying to relearn what I’d forgotten from my bass playing days in the the early nineties and figuring out what was possible to do with the Toneport.

At the beginning of October I was still enjoying playing and starting to understand the basics of recording.  I had also experimented with Reaper and Ableton Live as my DAW, but decided that if I were going to get serious and actually buy something, I wanted what the pros use even if realistically I won’t ever be a pro.  So I got a Protools mini in a package that came with studio monitors and a condensor microphone for my birthday.  Yes there are tons of other just as capable DAWs available, but that’s what I decided to go with and it’s been great.  Of course, now I’ve had lots to learn with playing the guitar and figuring out Protools, but that’s all part of the fun.  So now I had the pieces for the studio even though it was in the family room.

Then in January, the oldest daughter moved out.  After the musical chairs with the rooms was settled, I ended up with a room to double as my office and a home studio.  After some cleaning, new paint, and a trip to Ikea I was able to start settleing into my new digs.  The family was a big help with that!  This past month my wife and I have been able to find stuff to get on the walls and start to make it feel more homey.  Now that it’s pretty close to finished, I figured I better have a name, but I wasn’t sure would be a good one.  Then I remembered telling somebody after I’d been to a Tool concert that what I had heard was a sonic assuault on my body.  That stuck in my mind and seemed to be a perfect fit.  Now to the business of actually creating music!

In the raw

In the raw

You can always check out the rest of the set on my flickr page.

Advertisements

Testing Ariba Punch-out Scenarios

Posted: March 15, 2009 in B2B
Tags: , ,

I’ve finally had some time to work on the punch-out scenarios.  If you’re not familiar with what a punch-out is, it basically is a way for suppliers to give buyers real time catalog information without the hassle of catalog file going back and forth.  How real time is that?  When a buyer is interested in making a purchase a punch-out session is initiated and the suppliers punch-out site comes up.  Your site essentially is the catalog.  The end result when the buyer is done shopping, a quote sent back to the buyer for them to be able to turn it into a PO.  I’ll tackle the quote, or OrderMessage in cxml speak at a later time.  For now here are my punch-out scenarios:

Create punch-out session – like the PO scenarios this is the best one to start with as it is the most common and if this one does not work, there is not much point in going on.  With it you want to make sure the site comes up and is shoppable.

Inspect punch-out session – want to make sure that nothing can be edited in the cart.  No addition, subtractions, or quantity changes.  You also want to make sure that the buyer cannot navigate the site in other ways, like browsing products.

Edit punch-out session – want to make sure that items can be added and removed from the cart and that quantities can be changed.  This means the site must be navigable.

Create punch-out session with product specified – this is the same as the first scenario, but instead of a generic landing page, you should be directed to the detail page of the product specified.  Part of this should be what happens if a product is specified that does not exist.

Again the important part here is that both you and the trading company can feel confident that the system works for the expected scenarios.  Since Ariba does not keep track of these documents it can be even more important.  If your trading partner cannot even start the buying process they cannot buy your product.  Am I missing anything from these scenarios?

Testing Ariba PO Scenarios

Posted: March 10, 2009 in B2B
Tags: , ,

Since POs are the main document in the punch-out process, I figured I’d start with that one.  The fact that it is also the one I’ve done the most work on so far has nothing to do with it at all.   Please keep in mind that while I’m specifically calling out Ariba and cxml in these scenarios, the underlying xml format is not really the focus.  I’ve used these for implmentations with no VAN and the EBP xml format with just as good an efffect.  What I hope to do is just show that if the following scenarios pass, that I have a certain level of confidence my system will handle what is thrown at it.  I can’t imagine I’m alone in doing this type of work.

If you’re still reading, thanks!  I’ve broken the PO tests into subcategories to make it more organized and because some subcategories are unnecessary in some implementations.   They are:  single location scenarios, multiple location scenarios, override scenarios, and exception scenarios.  For each scenario I try to set up actual data in a table in my document.  It  includes addresses and products.  That way as the trading partner and I work through them I can keep a record of what has passed or not.  By the way, these are catalog orders so we have part numbers to go against.  Onward!

Single location scenarios:

  • One line order – just want to get the easiest one out of the way.  If this doesn’t work, not much point in moving on.
  • Multiple line order – at least 3 line items, want to make sure any line rules work.
  • One line order with backordered product – want to make sure there are no issue with a product not immediately shipping and it helps verify correct information in the POA.
  • One line order with discontinued product – want to make sure a PO in which all lines will be rejected still processes correctly.  Also helps verify correct behavior with the POA.
  • Multiple line order with a backordered line – verify a product that won’t be shipped immediately doesn’t block.  POA information a factor as well.
  • Multiple line order with discontinued product – verifying that an invalid line won’t block ordering of valid product.  POA information a factor as well.

Multiple location scenarios – because the cxml can differ in these situations as well as the ERP systems behind them:

  • 2 location one line each – again setting the baseline
  • 2 location 2 lines each – checking that line rules are still in effect even with multiple locations.
  • 2 location one backordered line – checking processing and POA
  • 2 location one discontinued line – checking processing and POA, I will typically do one with the discontinued product in the first location and one in the second.
  • 3 location order – just making sure no assumptions with 2 locations.  If this passes theoretically it will process as many as necessary.
  • 3 location order with the same product on each line – checking processing of the same product, some systems might combine them on one line potentially causing invoice issues later on.
  • 2 location order with non-sequential locations – typically do line 1 to a location, line 2 to a different location, and then line 3 to the same location as the first.  Making sure everything gets put together correctly.

Override scenarios – making sure things we have defaults for can be changed by the customer.  Will also check the below with multiple locations if necessary:

  • Ship method override – ensuring the PO can set the correct shipping method.
  • Ship complete override – ensuring the PO can set the correct ship complete option.

Exception scenarios – of course every order comes through perfectly!:

  • Duplicate orders – ensure they are handled according to company policy.
  • Change/delete orders – ensure they are handled according to company policy.
  • City/State/Zip combos – ensure they are handled according to company policy.
  • International orders – this might be a stretch to call them exceptions, but depending on the business these might be far and few between.  Ensure they are handled according to company policy.
  • Custom business rule check – every company has specific rules and quirks that need to be handled appropriately.

Once the trading partner sends in tests and we process them correctly we should now feel confident moving this document into production.  It doesn’t mean problems won’t happen, but I’m finding by doing this at a minimum the doh! problems are avoided and the implementation goes quicker and smoother.

To be honest, this is the kind of thing I’m a little surprised not to find in Ariba documentation or at least on the web somewhere.  Tons of these implementations must be happening and it seems like the easier they are the faster both partners can get on with the actual business instead of fussing over the little details.  Am I crazy or just searching on the wrong thing?

Some updates

Posted: March 8, 2009 in Uncategorized
Tags: ,

I’m realizing it’s been practically a year since I really actively posted, so thought I’d throw out some updates.

The Mazda 3:  Still absolutely loving it!  I’ve been relentless in trying to keep it clean, though Seattle winters make it tough to really keep it clean.  Mostly been annoying the kids and the wife about what they do when they’re in and around it.  No, it’s not weird to watch where your feet are going when you get in the car and for me to panic every time they open a door! 🙂

The Zune:  Also still loving it!  I have everything we own ripped now and on the Zune.  Gotta be careful though about letting the daughter play Kidz Bop since it shows up on the recently played list.  However, what’s made it even better are the changes to the Zune pass.  I didn’t even think about that until they allowed you to keep 10 songs per month.  I have done more music exploration since November than anytime I can remember in my life.  I know everyone raves about the iPod, but I wouldn’t give up my Zune now.  Extra bonus, the Mariners flagship radio station KIRO has now moved to the FM dial so I’ve been able to listen to the spring training games at work.  Try that iPod!

Testing Documents with Ariba

Posted: March 8, 2009 in B2B
Tags: ,

I’ve seen a lot of stuff about how Ariba can help you control your spend and how great it is for managers to see the information about where they are spending money.  What I haven’t seen is how Ariba, and by extension CXML, can use technology to help actually drive down the cost of transactions.  More importantly, given that automation should be the end goal, where is the documentation for helping people understand better what makes a good implemention using a solution with Ariba/cxml.

Yes, there is the users guide.  That does provide insight into what is cxml and how Ariba does use it.  However, it seems weird to me that there doesn’t seem to be any real worlddocumentation or best practices around how one should test the various document scenarios to ensure the system is solid between Ariba and the supplier/buyer.   If you’re constantly troubleshooting, it really isn’t saving that much money and you are just annoying the buyers.

I see the basic document path like the following:  punch-out -> quote (order message) -> purchase order -> PO acknowledgment -> ASN -> invoice

Question that I’d be very interested in seeing some answers would be along these lines. I realize these are open ended but I’ve got to start somewhere.

As I’m doing an implementation what are some specific concerns with each document?  What are the common pitfalls?  How do I articulate that I both understand those pitfalls and my system can handle them to my next trading partner?  How do we both know when we’re really ready to move into production?

In the next little bit I’ll be trying to throw out what answers I have and maybe it’ll start something.